Symptom
GET /api/v1/meta/diagnostics reports 94 of 94 registry entries as INVALID — every entry in the registry, sys_* and showcase_* alike, with no exceptions.
There are only two distinct error shapes behind all 94:
fields.__search: Unrecognized key 'index'
config: expected record, received undefined
Both are self-inflicted: __search is the platform's own auto-added search column, and the entries are otherwise healthy — they serve, they round-trip, and nothing else in the run pointed at broken schemas.
Expected: a healthy registry validates clean, and the diagnostics endpoint's verdict means something. At 94/94 INVALID the endpoint carries no signal — a genuinely broken object is indistinguishable from the baseline, so any future gate or dashboard built on it reads as permanently red.
Root cause
Not located by the report at code level. The evidence constrains it to the validator/producer seam rather than to the objects being validated:
- The rejected key
index on fields.__search is written by the platform when it provisions the search companion column, and FieldSchema does not admit that key — so either the writer is stamping a key it should not, or the schema is missing a key it must accept. One of the two is wrong; the report does not say which.
config: expected record, received undefined is the same class: the shape validation expects a record that the registry entry does not carry at all.
Same family as a fix that already landed — read it first
#6810 (closed 2026-08-08, domain:engine-core): "applySystemFields stamps indexed on organization_id — a key FieldSchema rejects by name, so every registry-backed object read answers _diagnostics: { valid: false }". That is the identical mechanism — a platform-stamped system field carrying a key the field schema rejects, invalidating every object — one field and one key over.
Its fix closed before this build was cut (a86db175, 2026-08-10), so the organization_id/indexed instance is presumably gone and this is the next instance of the same class (__search/index) rather than a regression of #6810 itself. Worth treating as such: fixing one key at a time will keep producing this card. The durable fix is to make the system-field stamper and FieldSchema share one vocabulary, and — separately — to give the diagnostics endpoint a pin that fails when the baseline registry is not clean, since 94/94 INVALID survived undetected until a manual QA read.
Reproduction
- Boot the showcase.
GET /api/v1/meta/diagnostics.- All 94 entries report INVALID; group the errors — only the two shapes above appear, across both
sys_* and showcase_* entries.
Source
Extracted from the QA run #7514 (framework a86db17, console 09987b68).
Symptom
GET /api/v1/meta/diagnosticsreports 94 of 94 registry entries as INVALID — every entry in the registry,sys_*andshowcase_*alike, with no exceptions.There are only two distinct error shapes behind all 94:
Both are self-inflicted:
__searchis the platform's own auto-added search column, and the entries are otherwise healthy — they serve, they round-trip, and nothing else in the run pointed at broken schemas.Expected: a healthy registry validates clean, and the diagnostics endpoint's verdict means something. At 94/94 INVALID the endpoint carries no signal — a genuinely broken object is indistinguishable from the baseline, so any future gate or dashboard built on it reads as permanently red.
Root cause
Not located by the report at code level. The evidence constrains it to the validator/producer seam rather than to the objects being validated:
indexonfields.__searchis written by the platform when it provisions the search companion column, andFieldSchemadoes not admit that key — so either the writer is stamping a key it should not, or the schema is missing a key it must accept. One of the two is wrong; the report does not say which.config: expected record, received undefinedis the same class: the shape validation expects a record that the registry entry does not carry at all.Same family as a fix that already landed — read it first
#6810 (closed 2026-08-08,
domain:engine-core): "applySystemFieldsstampsindexedonorganization_id— a keyFieldSchemarejects by name, so every registry-backed object read answers_diagnostics: { valid: false }". That is the identical mechanism — a platform-stamped system field carrying a key the field schema rejects, invalidating every object — one field and one key over.Its fix closed before this build was cut (
a86db175, 2026-08-10), so theorganization_id/indexedinstance is presumably gone and this is the next instance of the same class (__search/index) rather than a regression of #6810 itself. Worth treating as such: fixing one key at a time will keep producing this card. The durable fix is to make the system-field stamper andFieldSchemashare one vocabulary, and — separately — to give the diagnostics endpoint a pin that fails when the baseline registry is not clean, since 94/94 INVALID survived undetected until a manual QA read.Reproduction
GET /api/v1/meta/diagnostics.sys_*andshowcase_*entries.Source
Extracted from the QA run #7514 (framework a86db17, console 09987b68).