Skip to content

finding(plugin-grid/app-shell): the record-title key exists in THREE spellings, and lookup_filters/lookupFilters in two — one concept, several names, each only reconciled with itself #7021

Open
Open
finding(plugin-grid/app-shell): the record-title key exists in THREE spellings, and lookup_filters/lookupFilters in two — one concept, several names, each only reconciled with itself#7021
Labels
domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatfindingpm:queuepriority:p3

Description

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

Filed unassigned by the domain:ui execution seat (PM session session_013hfmP9hoMd3dJwTh85J4yB) — recording, not claiming.

Provenance: surfaced by the reader sweep on #6874 (landed as PR #7020). The dev reported these rather than acting on them, per its dispatch order; ⛔ nothing below was touched by that PR.

Dedupe: searched before filing, and the nil result is a reading rather than a blind instrument — a control query in the same session returned #6874 / #6875 / #6711 (10 hits, all on-topic) while the spelling-fork query returned 0. No open card covers this.

⛔ What this is NOT

Not a dead-key finding. Every spelling below has live readers.#6874 retired titleFormat from RELATIONAL_META_KEYS because it had no field-meta reader; that is a different question and it is settled. This card is about one concept carried under several names, which is the field || schema shape AGENTS.md #0.1 and #3233 forbid — and which is what lets a correctly-authored value parse clean and reach nothing.

Fork 1 — the record-title key, in THREE spellings

spellingsitereceiver
titleFormatcore/utils/record-title.ts:432, components/.../containers.tsx:1687, plugin-detail/DetailView.tsx:93, ObjectKanban.tsx:338, ObjectCalendar.tsx:428, react/hooks/useRecordSearch.ts:57, fields/widgets/LookupField.tsx:377OBJECT schema (incl. the referenced object's, via getSchema(referenceTo))
titleFormatapp-shell/utils/paramToField.ts:181a resolved ActionParamDef
title_formatapp-shell/utils/resolveActionParams.ts:536an object-schema field def

The third is the interesting one: snake_case, read off a field def, sitting one module away from a camelCase read of what is evidently the same concept. Until PR #7020, ObjectGrid was separately copying titleFormat (camelCase) onto field metas where nothing read it — so the tree has recently carried a camelCase field-def write that reached nothing and a snake_case field-def read that does, for the same idea.

Fork 2 — lookup_filters / lookupFilters, both in the same list

Both are members of RELATIONAL_META_KEYS (plugin-grid/src/ObjectGrid.tsx) and both are read, at the same two sites, as the two arms of a single ??:

  • fields/src/widgets/LookupField.tsx:270
  • fields/src/widgets/UserField.tsx:53

⇒ the camelCase arm is reachable only when a def carries it and not the snake_case one. So the fork is not decorative: which arm answers depends on how the def happened to be authored, and nothing tells an author the two are the same key.

Why it is finding and p3 rather than a bug

No measured user-visible defect: each fork's readers do resolve today, because each read site tolerates both arms or reads the one its own producer writes. The cost is drift risk and author confusion, not a live failure — the same grading #6887 got for a declaration copy. ⛔ Not raised to p2 without a measured case of a legally-authored value reaching nothing.

What a round would need to decide (⛔ no disposition proposed)

  1. Is the record-title concept actually one concept across all three sites, or does ActionParamDef.titleFormat legitimately mean something narrower than an object schema's? ⚠️ This must be answered before any convergence — collapsing two genuinely different concepts is worse than the fork.
  2. Which spelling is canonical, and does the spec declare it? The convergence direction in this repo is fix the contract, never widen the consumer (AGENTS.md #0.1), so the answer has to come from @objectstack/spec, not from a majority vote among consumers.
  3. Whether the ?? fork in RELATIONAL_META_KEYS should be retired to one arm, and if so which — noting that removing either arm from the copy set is an accept-set narrowing for anyone authoring that spelling today, so it needs the announced-retirement treatment (ADR-0087 registries / retirementTombstone()), not a silent deletion.

Related

#6874 / PR #7020 (the retirement that surfaced this), #6875 (the converse: keys the grid's picker reads but never receives), #3233 (field || schema, the same shape converged at its producers), #7014 (a parallel one-contract-many-declarations population).

Metadata

Metadata

Assignees

No one assigned

    Labels

    domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatfindingpm:queuepriority:p3

    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(plugin-grid/app-shell): the record-title key exists in THREE spellings, and `lookup_filters`/`lookupFilters` in two — one concept, several names, each only reconciled with itself · Issue #7021 · objectstack-ai/objectui · GitHub
      Skip to content
      finding(plugin-grid/app-shell): the record-title key exists in THREE spellings, and lookup_filters/lookupFilters in two — one concept, several names, each only reconciled with itself #7021
      Open
      Open
      finding(plugin-grid/app-shell): the record-title key exists in THREE spellings, and lookup_filters/lookupFilters in two — one concept, several names, each only reconciled with itself#7021
      Labels
      domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatfindingpm:queuepriority:p3
      Description
      @os-sam
      os-sam
      opened on Aug 31, 2026
      Filed unassigned by the domain:ui execution seat (PM session session_013hfmP9hoMd3dJwTh85J4yB) — recording, not claiming.
      Provenance: surfaced by the reader sweep on #6874 (landed as PR #7020). The dev reported these rather than acting on them, per its dispatch order; ⛔ nothing below was touched by that PR.
      Dedupe: searched before filing, and the nil result is a reading rather than a blind instrument — a control query in the same session returned #6874 / #6875 / #6711 (10 hits, all on-topic) while the spelling-fork query returned 0. No open card covers this.
      ⛔ What this is NOT
      Not a dead-key finding. Every spelling below has live readers.#6874 retired titleFormat from RELATIONAL_META_KEYS because it had no field-meta reader; that is a different question and it is settled. This card is about one concept carried under several names, which is the field || schema shape AGENTS.md #0.1 and #3233 forbid — and which is what lets a correctly-authored value parse clean and reach nothing.
      Fork 1 — the record-title key, in THREE spellings
      spellingsitereceiver
      titleFormatcore/utils/record-title.ts:432, components/.../containers.tsx:1687, plugin-detail/DetailView.tsx:93, ObjectKanban.tsx:338, ObjectCalendar.tsx:428, react/hooks/useRecordSearch.ts:57, fields/widgets/LookupField.tsx:377OBJECT schema (incl. the referenced object's, via getSchema(referenceTo))
      titleFormatapp-shell/utils/paramToField.ts:181a resolved ActionParamDef
      title_formatapp-shell/utils/resolveActionParams.ts:536an object-schema field def
      The third is the interesting one: snake_case, read off a field def, sitting one module away from a camelCase read of what is evidently the same concept. Until PR #7020, ObjectGrid was separately copying titleFormat (camelCase) onto field metas where nothing read it — so the tree has recently carried a camelCase field-def write that reached nothing and a snake_case field-def read that does, for the same idea.
      Fork 2 — lookup_filters / lookupFilters, both in the same list
      Both are members of RELATIONAL_META_KEYS (plugin-grid/src/ObjectGrid.tsx) and both are read, at the same two sites, as the two arms of a single ??:
      • fields/src/widgets/LookupField.tsx:270
      • fields/src/widgets/UserField.tsx:53
      ⇒ the camelCase arm is reachable only when a def carries it and not the snake_case one. So the fork is not decorative: which arm answers depends on how the def happened to be authored, and nothing tells an author the two are the same key.
      Why it is finding and p3 rather than a bug
      No measured user-visible defect: each fork's readers do resolve today, because each read site tolerates both arms or reads the one its own producer writes. The cost is drift risk and author confusion, not a live failure — the same grading #6887 got for a declaration copy. ⛔ Not raised to p2 without a measured case of a legally-authored value reaching nothing.
      What a round would need to decide (⛔ no disposition proposed)
      1. Is the record-title concept actually one concept across all three sites, or does ActionParamDef.titleFormat legitimately mean something narrower than an object schema's? ⚠️ This must be answered before any convergence — collapsing two genuinely different concepts is worse than the fork.
      2. Which spelling is canonical, and does the spec declare it? The convergence direction in this repo is fix the contract, never widen the consumer (AGENTS.md #0.1), so the answer has to come from @objectstack/spec, not from a majority vote among consumers.
      3. Whether the ?? fork in RELATIONAL_META_KEYS should be retired to one arm, and if so which — noting that removing either arm from the copy set is an accept-set narrowing for anyone authoring that spelling today, so it needs the announced-retirement treatment (ADR-0087 registries / retirementTombstone()), not a silent deletion.
      Related
      #6874 / PR #7020 (the retirement that surfaced this), #6875 (the converse: keys the grid's picker reads but never receives), #3233 (field || schema, the same shape converged at its producers), #7014 (a parallel one-contract-many-declarations population).
      Metadata
      Metadata
      Assignees
      No one assigned
        Labels
        domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatfindingpm:queuepriority:p3
        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(plugin-grid/app-shell): the record-title key exists in THREE spellings, and `lookup_filters`/`lookupFilters` in two — one concept, several names, each only reconciled with itself · Issue #7021 · objectstack-ai/objectui · GitHub
          Skip to content
          finding(plugin-grid/app-shell): the record-title key exists in THREE spellings, and lookup_filters/lookupFilters in two — one concept, several names, each only reconciled with itself #7021
          Open
          Open
          finding(plugin-grid/app-shell): the record-title key exists in THREE spellings, and lookup_filters/lookupFilters in two — one concept, several names, each only reconciled with itself#7021
          Labels
          domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatfindingpm:queuepriority:p3
          Description
          @os-sam
          os-sam
          opened on Aug 31, 2026
          Filed unassigned by the domain:ui execution seat (PM session session_013hfmP9hoMd3dJwTh85J4yB) — recording, not claiming.
          Provenance: surfaced by the reader sweep on #6874 (landed as PR #7020). The dev reported these rather than acting on them, per its dispatch order; ⛔ nothing below was touched by that PR.
          Dedupe: searched before filing, and the nil result is a reading rather than a blind instrument — a control query in the same session returned #6874 / #6875 / #6711 (10 hits, all on-topic) while the spelling-fork query returned 0. No open card covers this.
          ⛔ What this is NOT
          Not a dead-key finding. Every spelling below has live readers.#6874 retired titleFormat from RELATIONAL_META_KEYS because it had no field-meta reader; that is a different question and it is settled. This card is about one concept carried under several names, which is the field || schema shape AGENTS.md #0.1 and #3233 forbid — and which is what lets a correctly-authored value parse clean and reach nothing.
          Fork 1 — the record-title key, in THREE spellings
          spellingsitereceiver
          titleFormatcore/utils/record-title.ts:432, components/.../containers.tsx:1687, plugin-detail/DetailView.tsx:93, ObjectKanban.tsx:338, ObjectCalendar.tsx:428, react/hooks/useRecordSearch.ts:57, fields/widgets/LookupField.tsx:377OBJECT schema (incl. the referenced object's, via getSchema(referenceTo))
          titleFormatapp-shell/utils/paramToField.ts:181a resolved ActionParamDef
          title_formatapp-shell/utils/resolveActionParams.ts:536an object-schema field def
          The third is the interesting one: snake_case, read off a field def, sitting one module away from a camelCase read of what is evidently the same concept. Until PR #7020, ObjectGrid was separately copying titleFormat (camelCase) onto field metas where nothing read it — so the tree has recently carried a camelCase field-def write that reached nothing and a snake_case field-def read that does, for the same idea.
          Fork 2 — lookup_filters / lookupFilters, both in the same list
          Both are members of RELATIONAL_META_KEYS (plugin-grid/src/ObjectGrid.tsx) and both are read, at the same two sites, as the two arms of a single ??:
          • fields/src/widgets/LookupField.tsx:270
          • fields/src/widgets/UserField.tsx:53
          ⇒ the camelCase arm is reachable only when a def carries it and not the snake_case one. So the fork is not decorative: which arm answers depends on how the def happened to be authored, and nothing tells an author the two are the same key.
          Why it is finding and p3 rather than a bug
          No measured user-visible defect: each fork's readers do resolve today, because each read site tolerates both arms or reads the one its own producer writes. The cost is drift risk and author confusion, not a live failure — the same grading #6887 got for a declaration copy. ⛔ Not raised to p2 without a measured case of a legally-authored value reaching nothing.
          What a round would need to decide (⛔ no disposition proposed)
          1. Is the record-title concept actually one concept across all three sites, or does ActionParamDef.titleFormat legitimately mean something narrower than an object schema's? ⚠️ This must be answered before any convergence — collapsing two genuinely different concepts is worse than the fork.
          2. Which spelling is canonical, and does the spec declare it? The convergence direction in this repo is fix the contract, never widen the consumer (AGENTS.md #0.1), so the answer has to come from @objectstack/spec, not from a majority vote among consumers.
          3. Whether the ?? fork in RELATIONAL_META_KEYS should be retired to one arm, and if so which — noting that removing either arm from the copy set is an accept-set narrowing for anyone authoring that spelling today, so it needs the announced-retirement treatment (ADR-0087 registries / retirementTombstone()), not a silent deletion.
          Related
          #6874 / PR #7020 (the retirement that surfaced this), #6875 (the converse: keys the grid's picker reads but never receives), #3233 (field || schema, the same shape converged at its producers), #7014 (a parallel one-contract-many-declarations population).
          Metadata
          Metadata
          Assignees
          No one assigned
            Labels
            domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatfindingpm:queuepriority:p3
            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(plugin-grid/app-shell): the record-title key exists in THREE spellings, and `lookup_filters`/`lookupFilters` in two — one concept, several names, each only reconciled with itself · Issue #7021 · objectstack-ai/objectui · GitHub
              Skip to content
              finding(plugin-grid/app-shell): the record-title key exists in THREE spellings, and lookup_filters/lookupFilters in two — one concept, several names, each only reconciled with itself #7021
              Open
              Open
              finding(plugin-grid/app-shell): the record-title key exists in THREE spellings, and lookup_filters/lookupFilters in two — one concept, several names, each only reconciled with itself#7021
              Labels
              domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatfindingpm:queuepriority:p3
              Description
              @os-sam
              os-sam
              opened on Aug 31, 2026
              Filed unassigned by the domain:ui execution seat (PM session session_013hfmP9hoMd3dJwTh85J4yB) — recording, not claiming.
              Provenance: surfaced by the reader sweep on #6874 (landed as PR #7020). The dev reported these rather than acting on them, per its dispatch order; ⛔ nothing below was touched by that PR.
              Dedupe: searched before filing, and the nil result is a reading rather than a blind instrument — a control query in the same session returned #6874 / #6875 / #6711 (10 hits, all on-topic) while the spelling-fork query returned 0. No open card covers this.
              ⛔ What this is NOT
              Not a dead-key finding. Every spelling below has live readers.#6874 retired titleFormat from RELATIONAL_META_KEYS because it had no field-meta reader; that is a different question and it is settled. This card is about one concept carried under several names, which is the field || schema shape AGENTS.md #0.1 and #3233 forbid — and which is what lets a correctly-authored value parse clean and reach nothing.
              Fork 1 — the record-title key, in THREE spellings
              spellingsitereceiver
              titleFormatcore/utils/record-title.ts:432, components/.../containers.tsx:1687, plugin-detail/DetailView.tsx:93, ObjectKanban.tsx:338, ObjectCalendar.tsx:428, react/hooks/useRecordSearch.ts:57, fields/widgets/LookupField.tsx:377OBJECT schema (incl. the referenced object's, via getSchema(referenceTo))
              titleFormatapp-shell/utils/paramToField.ts:181a resolved ActionParamDef
              title_formatapp-shell/utils/resolveActionParams.ts:536an object-schema field def
              The third is the interesting one: snake_case, read off a field def, sitting one module away from a camelCase read of what is evidently the same concept. Until PR #7020, ObjectGrid was separately copying titleFormat (camelCase) onto field metas where nothing read it — so the tree has recently carried a camelCase field-def write that reached nothing and a snake_case field-def read that does, for the same idea.
              Fork 2 — lookup_filters / lookupFilters, both in the same list
              Both are members of RELATIONAL_META_KEYS (plugin-grid/src/ObjectGrid.tsx) and both are read, at the same two sites, as the two arms of a single ??:
              • fields/src/widgets/LookupField.tsx:270
              • fields/src/widgets/UserField.tsx:53
              ⇒ the camelCase arm is reachable only when a def carries it and not the snake_case one. So the fork is not decorative: which arm answers depends on how the def happened to be authored, and nothing tells an author the two are the same key.
              Why it is finding and p3 rather than a bug
              No measured user-visible defect: each fork's readers do resolve today, because each read site tolerates both arms or reads the one its own producer writes. The cost is drift risk and author confusion, not a live failure — the same grading #6887 got for a declaration copy. ⛔ Not raised to p2 without a measured case of a legally-authored value reaching nothing.
              What a round would need to decide (⛔ no disposition proposed)
              1. Is the record-title concept actually one concept across all three sites, or does ActionParamDef.titleFormat legitimately mean something narrower than an object schema's? ⚠️ This must be answered before any convergence — collapsing two genuinely different concepts is worse than the fork.
              2. Which spelling is canonical, and does the spec declare it? The convergence direction in this repo is fix the contract, never widen the consumer (AGENTS.md #0.1), so the answer has to come from @objectstack/spec, not from a majority vote among consumers.
              3. Whether the ?? fork in RELATIONAL_META_KEYS should be retired to one arm, and if so which — noting that removing either arm from the copy set is an accept-set narrowing for anyone authoring that spelling today, so it needs the announced-retirement treatment (ADR-0087 registries / retirementTombstone()), not a silent deletion.
              Related
              #6874 / PR #7020 (the retirement that surfaced this), #6875 (the converse: keys the grid's picker reads but never receives), #3233 (field || schema, the same shape converged at its producers), #7014 (a parallel one-contract-many-declarations population).
              Metadata
              Metadata
              Assignees
              No one assigned
                Labels
                domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatfindingpm:queuepriority:p3
                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(plugin-grid/app-shell): the record-title key exists in THREE spellings, and `lookup_filters`/`lookupFilters` in two — one concept, several names, each only reconciled with itself · Issue #7021 · objectstack-ai/objectui · GitHub
                  Skip to content
                  finding(plugin-grid/app-shell): the record-title key exists in THREE spellings, and lookup_filters/lookupFilters in two — one concept, several names, each only reconciled with itself #7021
                  Open
                  Open
                  finding(plugin-grid/app-shell): the record-title key exists in THREE spellings, and lookup_filters/lookupFilters in two — one concept, several names, each only reconciled with itself#7021
                  Labels
                  domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatfindingpm:queuepriority:p3
                  Description
                  @os-sam
                  os-sam
                  opened on Aug 31, 2026
                  Filed unassigned by the domain:ui execution seat (PM session session_013hfmP9hoMd3dJwTh85J4yB) — recording, not claiming.
                  Provenance: surfaced by the reader sweep on #6874 (landed as PR #7020). The dev reported these rather than acting on them, per its dispatch order; ⛔ nothing below was touched by that PR.
                  Dedupe: searched before filing, and the nil result is a reading rather than a blind instrument — a control query in the same session returned #6874 / #6875 / #6711 (10 hits, all on-topic) while the spelling-fork query returned 0. No open card covers this.
                  ⛔ What this is NOT
                  Not a dead-key finding. Every spelling below has live readers.#6874 retired titleFormat from RELATIONAL_META_KEYS because it had no field-meta reader; that is a different question and it is settled. This card is about one concept carried under several names, which is the field || schema shape AGENTS.md #0.1 and #3233 forbid — and which is what lets a correctly-authored value parse clean and reach nothing.
                  Fork 1 — the record-title key, in THREE spellings
                  spellingsitereceiver
                  titleFormatcore/utils/record-title.ts:432, components/.../containers.tsx:1687, plugin-detail/DetailView.tsx:93, ObjectKanban.tsx:338, ObjectCalendar.tsx:428, react/hooks/useRecordSearch.ts:57, fields/widgets/LookupField.tsx:377OBJECT schema (incl. the referenced object's, via getSchema(referenceTo))
                  titleFormatapp-shell/utils/paramToField.ts:181a resolved ActionParamDef
                  title_formatapp-shell/utils/resolveActionParams.ts:536an object-schema field def
                  The third is the interesting one: snake_case, read off a field def, sitting one module away from a camelCase read of what is evidently the same concept. Until PR #7020, ObjectGrid was separately copying titleFormat (camelCase) onto field metas where nothing read it — so the tree has recently carried a camelCase field-def write that reached nothing and a snake_case field-def read that does, for the same idea.
                  Fork 2 — lookup_filters / lookupFilters, both in the same list
                  Both are members of RELATIONAL_META_KEYS (plugin-grid/src/ObjectGrid.tsx) and both are read, at the same two sites, as the two arms of a single ??:
                  • fields/src/widgets/LookupField.tsx:270
                  • fields/src/widgets/UserField.tsx:53
                  ⇒ the camelCase arm is reachable only when a def carries it and not the snake_case one. So the fork is not decorative: which arm answers depends on how the def happened to be authored, and nothing tells an author the two are the same key.
                  Why it is finding and p3 rather than a bug
                  No measured user-visible defect: each fork's readers do resolve today, because each read site tolerates both arms or reads the one its own producer writes. The cost is drift risk and author confusion, not a live failure — the same grading #6887 got for a declaration copy. ⛔ Not raised to p2 without a measured case of a legally-authored value reaching nothing.
                  What a round would need to decide (⛔ no disposition proposed)
                  1. Is the record-title concept actually one concept across all three sites, or does ActionParamDef.titleFormat legitimately mean something narrower than an object schema's? ⚠️ This must be answered before any convergence — collapsing two genuinely different concepts is worse than the fork.
                  2. Which spelling is canonical, and does the spec declare it? The convergence direction in this repo is fix the contract, never widen the consumer (AGENTS.md #0.1), so the answer has to come from @objectstack/spec, not from a majority vote among consumers.
                  3. Whether the ?? fork in RELATIONAL_META_KEYS should be retired to one arm, and if so which — noting that removing either arm from the copy set is an accept-set narrowing for anyone authoring that spelling today, so it needs the announced-retirement treatment (ADR-0087 registries / retirementTombstone()), not a silent deletion.
                  Related
                  #6874 / PR #7020 (the retirement that surfaced this), #6875 (the converse: keys the grid's picker reads but never receives), #3233 (field || schema, the same shape converged at its producers), #7014 (a parallel one-contract-many-declarations population).
                  Metadata
                  Metadata
                  Assignees
                  No one assigned
                    Labels
                    domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatfindingpm:queuepriority:p3
                    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(plugin-grid/app-shell): the record-title key exists in THREE spellings, and `lookup_filters`/`lookupFilters` in two — one concept, several names, each only reconciled with itself · Issue #7021 · objectstack-ai/objectui · GitHub
                      Skip to content
                      finding(plugin-grid/app-shell): the record-title key exists in THREE spellings, and lookup_filters/lookupFilters in two — one concept, several names, each only reconciled with itself #7021
                      Open
                      Open
                      finding(plugin-grid/app-shell): the record-title key exists in THREE spellings, and lookup_filters/lookupFilters in two — one concept, several names, each only reconciled with itself#7021
                      Labels
                      domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatfindingpm:queuepriority:p3
                      Description
                      @os-sam
                      os-sam
                      opened on Aug 31, 2026
                      Filed unassigned by the domain:ui execution seat (PM session session_013hfmP9hoMd3dJwTh85J4yB) — recording, not claiming.
                      Provenance: surfaced by the reader sweep on #6874 (landed as PR #7020). The dev reported these rather than acting on them, per its dispatch order; ⛔ nothing below was touched by that PR.
                      Dedupe: searched before filing, and the nil result is a reading rather than a blind instrument — a control query in the same session returned #6874 / #6875 / #6711 (10 hits, all on-topic) while the spelling-fork query returned 0. No open card covers this.
                      ⛔ What this is NOT
                      Not a dead-key finding. Every spelling below has live readers.#6874 retired titleFormat from RELATIONAL_META_KEYS because it had no field-meta reader; that is a different question and it is settled. This card is about one concept carried under several names, which is the field || schema shape AGENTS.md #0.1 and #3233 forbid — and which is what lets a correctly-authored value parse clean and reach nothing.
                      Fork 1 — the record-title key, in THREE spellings
                      spellingsitereceiver
                      titleFormatcore/utils/record-title.ts:432, components/.../containers.tsx:1687, plugin-detail/DetailView.tsx:93, ObjectKanban.tsx:338, ObjectCalendar.tsx:428, react/hooks/useRecordSearch.ts:57, fields/widgets/LookupField.tsx:377OBJECT schema (incl. the referenced object's, via getSchema(referenceTo))
                      titleFormatapp-shell/utils/paramToField.ts:181a resolved ActionParamDef
                      title_formatapp-shell/utils/resolveActionParams.ts:536an object-schema field def
                      The third is the interesting one: snake_case, read off a field def, sitting one module away from a camelCase read of what is evidently the same concept. Until PR #7020, ObjectGrid was separately copying titleFormat (camelCase) onto field metas where nothing read it — so the tree has recently carried a camelCase field-def write that reached nothing and a snake_case field-def read that does, for the same idea.
                      Fork 2 — lookup_filters / lookupFilters, both in the same list
                      Both are members of RELATIONAL_META_KEYS (plugin-grid/src/ObjectGrid.tsx) and both are read, at the same two sites, as the two arms of a single ??:
                      • fields/src/widgets/LookupField.tsx:270
                      • fields/src/widgets/UserField.tsx:53
                      ⇒ the camelCase arm is reachable only when a def carries it and not the snake_case one. So the fork is not decorative: which arm answers depends on how the def happened to be authored, and nothing tells an author the two are the same key.
                      Why it is finding and p3 rather than a bug
                      No measured user-visible defect: each fork's readers do resolve today, because each read site tolerates both arms or reads the one its own producer writes. The cost is drift risk and author confusion, not a live failure — the same grading #6887 got for a declaration copy. ⛔ Not raised to p2 without a measured case of a legally-authored value reaching nothing.
                      What a round would need to decide (⛔ no disposition proposed)
                      1. Is the record-title concept actually one concept across all three sites, or does ActionParamDef.titleFormat legitimately mean something narrower than an object schema's? ⚠️ This must be answered before any convergence — collapsing two genuinely different concepts is worse than the fork.
                      2. Which spelling is canonical, and does the spec declare it? The convergence direction in this repo is fix the contract, never widen the consumer (AGENTS.md #0.1), so the answer has to come from @objectstack/spec, not from a majority vote among consumers.
                      3. Whether the ?? fork in RELATIONAL_META_KEYS should be retired to one arm, and if so which — noting that removing either arm from the copy set is an accept-set narrowing for anyone authoring that spelling today, so it needs the announced-retirement treatment (ADR-0087 registries / retirementTombstone()), not a silent deletion.
                      Related
                      #6874 / PR #7020 (the retirement that surfaced this), #6875 (the converse: keys the grid's picker reads but never receives), #3233 (field || schema, the same shape converged at its producers), #7014 (a parallel one-contract-many-declarations population).
                      Metadata
                      Metadata
                      Assignees
                      No one assigned
                        Labels
                        domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatfindingpm:queuepriority:p3
                        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); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
finding(plugin-grid/app-shell): the record-title key exists in THREE spellings, and `lookup_filters`/`lookupFilters` in two — one concept, several names, each only reconciled with itself · Issue #7021 · objectstack-ai/objectui · GitHub
                          Skip to content
                          finding(plugin-grid/app-shell): the record-title key exists in THREE spellings, and lookup_filters/lookupFilters in two — one concept, several names, each only reconciled with itself #7021
                          Open
                          Open
                          finding(plugin-grid/app-shell): the record-title key exists in THREE spellings, and lookup_filters/lookupFilters in two — one concept, several names, each only reconciled with itself#7021
                          Labels
                          domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatfindingpm:queuepriority:p3
                          Description
                          @os-sam
                          os-sam
                          opened on Aug 31, 2026
                          Filed unassigned by the domain:ui execution seat (PM session session_013hfmP9hoMd3dJwTh85J4yB) — recording, not claiming.
                          Provenance: surfaced by the reader sweep on #6874 (landed as PR #7020). The dev reported these rather than acting on them, per its dispatch order; ⛔ nothing below was touched by that PR.
                          Dedupe: searched before filing, and the nil result is a reading rather than a blind instrument — a control query in the same session returned #6874 / #6875 / #6711 (10 hits, all on-topic) while the spelling-fork query returned 0. No open card covers this.
                          ⛔ What this is NOT
                          Not a dead-key finding. Every spelling below has live readers.#6874 retired titleFormat from RELATIONAL_META_KEYS because it had no field-meta reader; that is a different question and it is settled. This card is about one concept carried under several names, which is the field || schema shape AGENTS.md #0.1 and #3233 forbid — and which is what lets a correctly-authored value parse clean and reach nothing.
                          Fork 1 — the record-title key, in THREE spellings
                          spellingsitereceiver
                          titleFormatcore/utils/record-title.ts:432, components/.../containers.tsx:1687, plugin-detail/DetailView.tsx:93, ObjectKanban.tsx:338, ObjectCalendar.tsx:428, react/hooks/useRecordSearch.ts:57, fields/widgets/LookupField.tsx:377OBJECT schema (incl. the referenced object's, via getSchema(referenceTo))
                          titleFormatapp-shell/utils/paramToField.ts:181a resolved ActionParamDef
                          title_formatapp-shell/utils/resolveActionParams.ts:536an object-schema field def
                          The third is the interesting one: snake_case, read off a field def, sitting one module away from a camelCase read of what is evidently the same concept. Until PR #7020, ObjectGrid was separately copying titleFormat (camelCase) onto field metas where nothing read it — so the tree has recently carried a camelCase field-def write that reached nothing and a snake_case field-def read that does, for the same idea.
                          Fork 2 — lookup_filters / lookupFilters, both in the same list
                          Both are members of RELATIONAL_META_KEYS (plugin-grid/src/ObjectGrid.tsx) and both are read, at the same two sites, as the two arms of a single ??:
                          • fields/src/widgets/LookupField.tsx:270
                          • fields/src/widgets/UserField.tsx:53
                          ⇒ the camelCase arm is reachable only when a def carries it and not the snake_case one. So the fork is not decorative: which arm answers depends on how the def happened to be authored, and nothing tells an author the two are the same key.
                          Why it is finding and p3 rather than a bug
                          No measured user-visible defect: each fork's readers do resolve today, because each read site tolerates both arms or reads the one its own producer writes. The cost is drift risk and author confusion, not a live failure — the same grading #6887 got for a declaration copy. ⛔ Not raised to p2 without a measured case of a legally-authored value reaching nothing.
                          What a round would need to decide (⛔ no disposition proposed)
                          1. Is the record-title concept actually one concept across all three sites, or does ActionParamDef.titleFormat legitimately mean something narrower than an object schema's? ⚠️ This must be answered before any convergence — collapsing two genuinely different concepts is worse than the fork.
                          2. Which spelling is canonical, and does the spec declare it? The convergence direction in this repo is fix the contract, never widen the consumer (AGENTS.md #0.1), so the answer has to come from @objectstack/spec, not from a majority vote among consumers.
                          3. Whether the ?? fork in RELATIONAL_META_KEYS should be retired to one arm, and if so which — noting that removing either arm from the copy set is an accept-set narrowing for anyone authoring that spelling today, so it needs the announced-retirement treatment (ADR-0087 registries / retirementTombstone()), not a silent deletion.
                          Related
                          #6874 / PR #7020 (the retirement that surfaced this), #6875 (the converse: keys the grid's picker reads but never receives), #3233 (field || schema, the same shape converged at its producers), #7014 (a parallel one-contract-many-declarations population).
                          Metadata
                          Metadata
                          Assignees
                          No one assigned
                            Labels
                            domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatfindingpm:queuepriority:p3
                            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)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();
finding(plugin-grid/app-shell): the record-title key exists in THREE spellings, and `lookup_filters`/`lookupFilters` in two — one concept, several names, each only reconciled with itself · Issue #7021 · objectstack-ai/objectui · GitHub
                              Skip to content
                              finding(plugin-grid/app-shell): the record-title key exists in THREE spellings, and lookup_filters/lookupFilters in two — one concept, several names, each only reconciled with itself #7021
                              Open
                              Open
                              finding(plugin-grid/app-shell): the record-title key exists in THREE spellings, and lookup_filters/lookupFilters in two — one concept, several names, each only reconciled with itself#7021
                              Labels
                              domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatfindingpm:queuepriority:p3
                              Description
                              @os-sam
                              os-sam
                              opened on Aug 31, 2026
                              Filed unassigned by the domain:ui execution seat (PM session session_013hfmP9hoMd3dJwTh85J4yB) — recording, not claiming.
                              Provenance: surfaced by the reader sweep on #6874 (landed as PR #7020). The dev reported these rather than acting on them, per its dispatch order; ⛔ nothing below was touched by that PR.
                              Dedupe: searched before filing, and the nil result is a reading rather than a blind instrument — a control query in the same session returned #6874 / #6875 / #6711 (10 hits, all on-topic) while the spelling-fork query returned 0. No open card covers this.
                              ⛔ What this is NOT
                              Not a dead-key finding. Every spelling below has live readers.#6874 retired titleFormat from RELATIONAL_META_KEYS because it had no field-meta reader; that is a different question and it is settled. This card is about one concept carried under several names, which is the field || schema shape AGENTS.md #0.1 and #3233 forbid — and which is what lets a correctly-authored value parse clean and reach nothing.
                              Fork 1 — the record-title key, in THREE spellings
                              spellingsitereceiver
                              titleFormatcore/utils/record-title.ts:432, components/.../containers.tsx:1687, plugin-detail/DetailView.tsx:93, ObjectKanban.tsx:338, ObjectCalendar.tsx:428, react/hooks/useRecordSearch.ts:57, fields/widgets/LookupField.tsx:377OBJECT schema (incl. the referenced object's, via getSchema(referenceTo))
                              titleFormatapp-shell/utils/paramToField.ts:181a resolved ActionParamDef
                              title_formatapp-shell/utils/resolveActionParams.ts:536an object-schema field def
                              The third is the interesting one: snake_case, read off a field def, sitting one module away from a camelCase read of what is evidently the same concept. Until PR #7020, ObjectGrid was separately copying titleFormat (camelCase) onto field metas where nothing read it — so the tree has recently carried a camelCase field-def write that reached nothing and a snake_case field-def read that does, for the same idea.
                              Fork 2 — lookup_filters / lookupFilters, both in the same list
                              Both are members of RELATIONAL_META_KEYS (plugin-grid/src/ObjectGrid.tsx) and both are read, at the same two sites, as the two arms of a single ??:
                              • fields/src/widgets/LookupField.tsx:270
                              • fields/src/widgets/UserField.tsx:53
                              ⇒ the camelCase arm is reachable only when a def carries it and not the snake_case one. So the fork is not decorative: which arm answers depends on how the def happened to be authored, and nothing tells an author the two are the same key.
                              Why it is finding and p3 rather than a bug
                              No measured user-visible defect: each fork's readers do resolve today, because each read site tolerates both arms or reads the one its own producer writes. The cost is drift risk and author confusion, not a live failure — the same grading #6887 got for a declaration copy. ⛔ Not raised to p2 without a measured case of a legally-authored value reaching nothing.
                              What a round would need to decide (⛔ no disposition proposed)
                              1. Is the record-title concept actually one concept across all three sites, or does ActionParamDef.titleFormat legitimately mean something narrower than an object schema's? ⚠️ This must be answered before any convergence — collapsing two genuinely different concepts is worse than the fork.
                              2. Which spelling is canonical, and does the spec declare it? The convergence direction in this repo is fix the contract, never widen the consumer (AGENTS.md #0.1), so the answer has to come from @objectstack/spec, not from a majority vote among consumers.
                              3. Whether the ?? fork in RELATIONAL_META_KEYS should be retired to one arm, and if so which — noting that removing either arm from the copy set is an accept-set narrowing for anyone authoring that spelling today, so it needs the announced-retirement treatment (ADR-0087 registries / retirementTombstone()), not a silent deletion.
                              Related
                              #6874 / PR #7020 (the retirement that surfaced this), #6875 (the converse: keys the grid's picker reads but never receives), #3233 (field || schema, the same shape converged at its producers), #7014 (a parallel one-contract-many-declarations population).
                              Metadata
                              Metadata
                              Assignees
                              No one assigned
                                Labels
                                domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatfindingpm:queuepriority:p3
                                Type
                                No type
                                Projects
                                No projects
                                  Milestone
                                  No milestone
                                  Relationships
                                  None yet
                                  Development
                                  No branches or pull requests
                                  Issue actions