fix(ci): align schema-smoke with current migrations layout - #34
Closed
iret77 wants to merge 1 commit into
Closed
Conversation
The pinned migrations list in .github/workflows/ci.yml was stale: four files had moved from middleware/src/services/graph/migrations/ to the harness-knowledge-graph-neon package, and two had been renumbered (0007->0012, 0008->0013) as five new migrations were inserted ahead of them. The schema (migrations on pgvector) job has been failing since Actions were reactivated this morning. Replace the hardcoded array with a loop over five migration domains (graph, auth, routines, profileSnapshots, profileStorage). Files within a domain apply in lexical (numbered) order; domains apply in dependency order. New migrations are now picked up automatically without requiring a workflow edit.
This was referenced May 17, 2026
Contributor
Author
|
Superseded by #35 (consolidated CI resurrection). Under the strict branch protection with |
Weegy
added a commit
that referenced
this pull request
Jun 16, 2026
…r-2) Makes Lumens reachable end-to-end over a live server (the producer half of #34): - canvas_publish_lumen — a canvas-output producer that instantiates a vetted reference Lumen (variant: arcade game · interactive map · defrag animation) as a surface_snapshot. Authorised in the canvas-output allow-set AND the deterministic-action allow-set, so a canvas action of that type dispatches LLM-free (a click renders the Lumen with no model turn). - referenceLumens.ts — the three vetted reference Lumens (declarative LX data), each exercising a different slice: tick simulation + events, interactive selection/zoom via get/if, and a map(range) tick animation. - treeValidator: extended additively to omadia-canvas-protocol/1.1 — the 1.0 canvas-tree with scene + lumen added to the primitive oneOf, so a snapshot carrying a Lumen validates server-side. Depends on the canvas-core 1.1 schemas in this PR.
Weegy
added a commit
that referenced
this pull request
Jun 16, 2026
… (server) (#315) * feat(canvas-core): Lumens (Live Interactivity) protocol 1.1 — schemas, LX interpreter, capability policy omadia-canvas-protocol/1.1, additive over 1.0 (PR byte5ai/omadia-ui#31, issue #34). - L0: lx-ast/scene/ports-wires/capability-manifest/lumen JSON schemas (+ var read node, get projection node) with accept/reject conformance fixtures. - L1: deterministic, gas+depth+value-size-bounded, no-eval LX interpreter with seeded random/now and a static semantic validator. Prototype-pollution hardened; all 10 findings from an adversarial (Forge/GPT-5.4) review fixed. - L5/L7/L8 Tier-2 policy (pure, consumed by the orchestrator when built): effect classification, broker egress bounds (rate/quota/in-flight/idempotency/ backpressure), content-addressed never-stale asset cache, import consent, content-addressed presets + resolve-then-generate + fork lineage, share token re-mint (assets travel by id, never the author token). - validateLumenFull combined gate. 172 tests, tsc clean. Land this before the omadia-ui UI PR (UI syncs these schemas). * feat(ui-orchestrator): Lumen producer tool + 1.1 tree validation (Tier-2) Makes Lumens reachable end-to-end over a live server (the producer half of #34): - canvas_publish_lumen — a canvas-output producer that instantiates a vetted reference Lumen (variant: arcade game · interactive map · defrag animation) as a surface_snapshot. Authorised in the canvas-output allow-set AND the deterministic-action allow-set, so a canvas action of that type dispatches LLM-free (a click renders the Lumen with no model turn). - referenceLumens.ts — the three vetted reference Lumens (declarative LX data), each exercising a different slice: tick simulation + events, interactive selection/zoom via get/if, and a map(range) tick animation. - treeValidator: extended additively to omadia-canvas-protocol/1.1 — the 1.0 canvas-tree with scene + lumen added to the primitive oneOf, so a snapshot carrying a Lumen validates server-side. Depends on the canvas-core 1.1 schemas in this PR. * feat(ui-orchestrator): agent-authored Lumens (dynamic LLM generation) canvas_publish_lumen now PREFERS an agent-authored `lumen` (the real thesis: the LLM generates declarative LX data; the host validates it). The tool validates the authored Lumen structurally (validateLumenNode against the 1.1 lumen schema) and, on failure, returns a path-pointed error so the agent self-corrects — this is what makes LLM-generated interactivity safe (the model proposes data, the host proves it bounded/total/deterministic before it runs). The tool description carries the compact LX grammar + a worked example. The `variant` reference presets remain as a canned-demo fallback (resolve-then- generate). Semantic bounds beyond the schema are enforced Tier-1 by the interpreter (halts a bad Lumen with surface_error, never the canvas). * feat(ui-orchestrator): data-bound Lumens from real privacy-shielded datasets (L5 loadData) canvas_publish_lumen now also takes a privacy-shield `datasetId` (+ optional labelField/valueField). The real rows are resolved SERVER-SIDE via the same privacy provider canvas_publish_rows uses — the unmasked data never reaches the LLM — and an interactive, tappable data Lumen is built deterministically in datasetLumen.ts (one selectable row per record; tap highlights via a state-driven conditional). This is the privacy-safe answer to 'visualise the user's real data as a live artifact': the model only passes the dataset handle, the host resolves + constructs. Locally verified (validateLumen ok; view + tap transition evaluate correctly). * feat(ui-orchestrator): accept inline data rows for data-bound Lumens Adds a `data` param to canvas_publish_lumen: when the agent already HOLDS the rows (an unshielded fetch — e.g. dynamics tools in bypass mode emit real rows directly, no datasetId interned), it passes them as `data` and the server builds the interactive data Lumen via buildDatasetLumen — no LX authoring needed. Complements `datasetId` (masked/shielded path, resolved server-side). Tool description now steers: visible rows → `data`, masked → `datasetId`. * test(ui-orchestrator): include canvas_publish_lumen in producer-tool registration assertions The producer now registers three canvas-output tools (rows + choice + lumen); update the registration/dispose assertions accordingly (3 registered, 3 disposed).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
schema (migrations on pgvector)job has been failing since Actions were reactivated this morning. The hardcodedMIGRATIONSarray in.github/workflows/ci.ymlpointed at a stale layout: four files had moved frommiddleware/src/services/graph/migrations/into theharness-knowledge-graph-neonpackage, and two had been renumbered (0007->0012,0008->0013) as five new migrations were inserted ahead of them.graph,auth,routines,profileSnapshots,profileStorage). Files inside a domain apply in lexical (numbered) order; domains apply in dependency order.auth,profileSnapshots,profileStoragedomains and the newer routines/graph entries. New migrations will be picked up automatically — no more workflow edits to keep CI honest.No application code, no migrations, no
package.jsontouched — only.github/workflows/ci.yml.Test plan
schema (migrations on pgvector)turns green for the first time since Actions were re-enabled.IF NOT EXISTS-safe).web-uiandrelease-blockerremain green.middlewareandaudit (middleware)are expected to keep failing until the parallel Node-20→22 PR lands; that's tracked separately and not in scope here.