Queryable not-xray image view: count + % of uploaded práctica images flagged as NOT a real radiografía. Elazar 2026-06-26: he has not seen one real x-ray — ~99% are photos of a monitor screen, not actual radiographs. The image-analysis path already produces a flag (a 3-letter code/word per Elazar) that marks an image as not-an-xray. Build a DB view (db + coder) over the existing image-analysis data (likely imageUploadAnalysisEvents) that reports total images vs flagged-not-xray count and percentage, queryable any time (overall + optionally by periodo/comisión/recent-window). FIRST identify the actual flag field + its not-xray value. Read/analysis surface only, no enforcement/blocking. Build deferred — tracking only.

Sub-tickets

Activity

• wi-cli-venus created · 2026-06-26
• wi-cli-venus decision · 4w ago
  THE ROW'S PREMISE IS FALSE AND THAT CHANGES WHAT IT IS. Measured read-only 2026-09-12 by coder02-enamel-cc against the live schema: imageUploadAnalysisEvents has NO flag column anywhere - there is a detail jsonb and nothing else. The row was written on Elazar's 2026-06-26 statement that 'the image-analysis path already produces a flag (a 3-letter code/word per Elazar) that marks an image as not-an-xray', and its step 0 is 'FIRST identify the actual flag field + its not-xray value'. That step is not merely unbuilt, it is UNADDRESSABLE: the thing it asks you to identify does not exist. This is not a small correction. As filed the row is a VIEW over existing data - cheap, read-only, a db+coder afternoon. What it actually requires is PRODUCING the classification first, which is an image-analysis capability, not a query. Those are different projects with different costs and different owners, and the second one cannot be given a GO on the strength of an estimate made for the first. Elazar's underlying observation is untouched and still worth acting on - he says ~99 percent of uploads are photographs of a monitor rather than radiographs, and nothing here disputes that. What is wrong is only the belief that the system already records it. Blocking on his call rather than silently rescoping: does he want the classifier built, or was he recalling a field from a different surface. Status moved backlog -> blocked so the premise defect lives in a queryable field instead of in this event body. Do NOT build a view over detail jsonb to approximate the flag - a heuristic standing in for a measurement, in a row whose whole purpose is to produce a trustworthy count, is a new failure mode rather than a fix.
• wi-cli-venus blocked · 4w ago
  Row's stated premise is false: no not-an-xray flag column exists on imageUploadAnalysisEvents (detail jsonb only), so step 0 is unaddressable. Needs Elazar: build the classifier, or was he recalling a different surface?
• pmmaster-evolutiva-cc unblocked · 1w ago
  Unblocked and re-pointed by pmmaster-evolutiva-cc 2026-10-06. The row was parked on an Elazar question - build the classifier, or was he misremembering - and that question is premature because nobody has read the data yet. The block says 'no not-an-xray flag COLUMN exists on imageUploadAnalysisEvents (detail jsonb only)'. A null or absent COLUMN is a fact about the column; the payload is jsonb and Elazar described a 3-letter code, which is exactly the shape that lives in a jsonb value rather than a promoted column. FIRST STEP, read-only, db lane: census the distinct keys present in imageUploadAnalysisEvents.detail, and for any key whose values look like short codes, census those values with counts. One pass. THEN one of three things is true and each is actionable without Elazar: (a) a code exists and marks not-an-xray - build the view as originally specified, read/analysis only, no enforcement; (b) a code exists but means something else - report what it means and the row becomes a classifier request with a known starting point; (c) detail carries no such code at all - THEN it is an Elazar question, and it is a precise one ('the analysis path records X, not a not-xray flag; do you want one built?') instead of 'was he recalling a different system'. Build stays deferred until the census answers. Do not implement any blocking or enforcement on uploads under any branch.
• db-mars-ca assigned · 1w ago
  db-mars-ca / db
• db-mars-ca blocked · 1w ago
  Live Mars DB catalog contains no public imageUploadAnalysisEvents relation (no matching analysis/upload-event table in public); read-only key/value census cannot run. Local migration 003 defines the table, but it is absent from this live project. Need clarify intended deployed analysis data source/project before proceeding.
• db-mars-ca note · 1w ago
  Read-only live check 2026-10-06 as agent_db_mars_ca. Exact census attempted: SELECT count(*) FROM public."imageUploadAnalysisEvents"; failed ERROR: relation "public.imageUploadAnalysisEvents" does not exist. Follow-up catalog query: SELECT n.nspname,c.relname,c.relkind FROM pg_class c JOIN pg_namespace n ON n.oid=c.relnamespace WHERE c.relname ILIKE '%image%' AND n.nspname NOT IN ('pg_catalog','information_schema') ORDER BY 1,2; found only image tables/views for practice images and vProfileImageUploadEvents, no analysis-events relation. Public relname query for '%analysis%' or '%upload%event%' found only vProfileImageUploadEvents. Therefore keys/code values were NOT censused; absence of the requested table is not evidence that no classification code exists in another source. Repo migration db/migrations/applied/003-2026-04-08-image-upload-analysis-events.sql defines the expected public table. No DB changes.
• db-mars-ca unblocked · 1w ago
  Read-only catalog check via pg_catalog on verified Mars project found no imageUploadAnalysisEvents relation in any schema. Not an information_schema visibility result. api-images remains a possible external source but was not verified; determine that source before any view work.
• db-mars-ca note · 1w ago
  Correction after direct catalog discriminator (2026-10-06): this connection is to Mars ref ustenjufophwhlkzfdso, verified from the DSN username suffix agent_db_mars_ca. Pooler hostname is shared (aws-1-sa-east-1.pooler.supabase.com), so host alone is not project proof. Exact direct catalog query executed: SELECT n.nspname,c.relname,c.relkind,pg_get_userbyid(c.relowner) AS owner,has_table_privilege(current_user,c.oid,'SELECT') AS can_select FROM pg_catalog.pg_class c JOIN pg_catalog.pg_namespace n ON n.oid=c.relnamespace WHERE c.relname ILIKE '%upload%' OR c.relname ILIKE '%analysis%' OR c.relname ILIKE '%image%' ORDER BY n.nspname,c.relname. This returned 21 catalog objects; none named imageUploadAnalysisEvents (the only public upload-event-like relation was vProfileImageUploadEvents, a different profile-image surface). pg_class is directly queryable under this role; thus result is not information_schema privilege filtering. Correct classification: genuinely absent from the verified Mars database, not invisible and not wrong project. This proves only that the table is absent, not that the analysis data lives in api-images. Source inspection in the Mars repo shows IMAGE_API_BASE_URL integration for image operations and public.classify_image(text) for image ownership/scope, but no not-an-xray analysis writer/reader; api-images source is not present in the available workspace (only orphan-reconciliation artifacts). External api-images storage of an analysis code remains unverified. No key/value census possible until its actual data source is identified. No DB changes.
• db-mars-ca note · 1w ago
  api-images read-only result received 2026-10-06 from coder-apiimages-cc: branch (c). Deployed branch and box inspection found no per-image analysis computation or output. Their checked install contains 18 non-image files (11 PHP plus config); analysis/classification/vision/provider/inference search over PHP had zero matches; no outbound HTTP client or third-party provider. Image inspection is limited to MIME/format validation via finfo/getimagesize and JPEG marker stripping; imagick/GD are excluded. The only log vocabulary is operational failures/purge/checksum/strip; 201 stored fields cover id, MIME, size, checksum/hash, dimensions, createdAt; storage contains jpg and service cache/purge metadata only. Service has no DB. Thus no persisted, discarded, or provider-returned not-an-xray code exists in api-images. Branch (c): the 2026-06-26 statement refers to another system/tool or a future/planned feature. Precise source question filed to Elazar; no build/enforcement started.
• db-mars-ca blocked · 1w ago
  api-images branch (c) confirmed: neither the Mars app nor api-images produces a not-an-xray code. Await Elazar identifying the system/tool behind the 2026-06-26 3-letter-code statement, or confirming there is no existing signal and authorizing scope to be reframed as a new classifier.
• db-mars-ca assigned · 6d ago
  db-mars-cc / db