Correction first: the deploy path was already fixed

This PR was opened to migrate ~12 integrations' demo assets out of LFS. That approach was dropped — the assets stay uniformly LFS-tracked and the build is the single place this gets resolved.

While establishing scope, one premise turned out to be false and it matters for how this gets prioritised:

showcase_build.yml does not read the per-slot "lfs" flag. ALL_SERVICES does carry "lfs":false for every integration, which reads as though integration images ship pointer stubs. They do not. The image-building build job (lines 418–604, containing the depot/build-push-action that pushes the deployed image) hardcodes lfs: true, added 2026-06-07 in 7bde1eef3aa — "ci(showcase): pull Git LFS assets during build so demo images ship real binaries" — for exactly this bug. The only reader of the flag was showcase_build_check.yml.

Evidence, from a real CI run on main (30116731237, job 89559665519, build (built-in-agent, …), 2026-07-24) — note built-in-agent is "lfs":false in ALL_SERVICES:

lfs: true
[command]/usr/bin/git lfs version
git-lfs/3.7.1 (GitHub; linux amd64; go 1.24.4)
[command]/usr/bin/git lfs install --local
##[group]Fetching LFS objects
[command]/usr/bin/git lfs fetch origin refs/remotes/origin/main

And confirmed end-to-end against what prod and staging actually serve — all 10 pointer-committed integrations, both assets:

PROD     ag2 built-in-agent claude-sdk-python claude-sdk-typescript crewai-crews
         langroid llamaindex ms-agent-harness-dotnet pydantic-ai spring-ai
           sample.png  200  10083 B  ‰PNG   real asset
           sample.pdf  200   2486 B  %PDF   real asset
STAGING  ag2, llamaindex, spring-ai, google-adk
           sample.png  200  10083 B  ‰PNG   real asset
PROD/STG agno, mastra   sample.png/pdf  404  absent   <- separate bug, PR #6157

So: zero integration images ship stubs, and there are no broken multimodal cells from this cause. The catalogued blast radius is not expanded. The agno/mastra failures are HTTP 404 from files being absent, a different root cause.

Two consequences worth flagging:

• fix(showcase): bundle multimodal sample assets for agno and mastra #6157 is not blocked on this PR. Once it adds agno/mastra's assets — as plain LFS-tracked files, no overrides — showcase_build.yml already fetches them, so their images get the real bytes on the next build.
• This PR is hardening, not an incident fix.

What this PR actually changes

Two paths genuinely did not fetch LFS:

test_e2e-showcase-on-demand.yml was the meaningful gap. It runs npx next dev on the integration package and drives it with Playwright, serving public/ straight from the working tree — so with no LFS fetch, multimodal.spec.ts clicks "Try with sample image", gets a ~130-byte pointer stub served as image/png, and fails the magic-byte guard in sample-attachment-buttons.tsx with nothing wrong in the code under test. Nine of the ten affected integrations ship that spec (all but ms-agent-harness-dotnet).

Making it not recur

The per-slot "lfs" field is deleted from both ALL_SERVICES definitions. After the change above it had no consumers — showcase_build.yml ignored it in favour of a hardcoded true, and showcase_build_check.yml was its only reader.

Deleting it rather than setting it to true is deliberate: a dead flag that reads as authoritative is how this got mis-set in the first place, and it is what made the state so hard to reason about here. With no flag, integration #21 cannot be added with LFS fetching silently off — there is nothing to set and nothing to forget. Both JSON blobs were re-parsed after the edit (28 and 26 services, zero lfs keys).

Residual risk, stated plainly: every fetch site is now a literal lfs: true, so correctness rests on a new workflow that serves integration assets remembering to include it. That is a smaller and more visible surface than a per-service flag, but it is not structurally enforced. A CI guard asserting that any workflow checking out showcase/integrations/* passes lfs: true would close it; not in this PR.

Verified affected list — 10 integrations, not 12

Pointer-committed public/demo-files/sample.{png,pdf} on main, established from the committed tree (local LFS smudge makes the working tree lie — ls -l shows 10083 B for a 130 B pointer):

ag2, built-in-agent, claude-sdk-python, claude-sdk-typescript, crewai-crews, langroid, llamaindex, ms-agent-harness-dotnet, pydantic-ai, spring-ai

Sizes via the LFS-unaware git/trees API: sample.png 130 B, sample.pdf 129 B (real: 10083 B / 2486 B). Note the contents API is LFS-aware and reports the resolved 10083 B for pointers too, so it cannot be used to tell them apart.

The "12" figure conflated two root causes: these 10 have pointer stubs (correct LFS state, harmless), while agno/mastra had the files absent (HTTP 404, genuinely broken, #6157).

Already carrying per-integration overrides, untouched here: google-adk, langgraph-python, langgraph-fastapi, langgraph-typescript, strands, strands-typescript, ms-agent-dotnet, ms-agent-python. Consolidating those onto the uniform LFS convention is a separate follow-up.

Bandwidth cost

Negligible for the assets themselves — sample.png 10083 B + sample.pdf 2486 B ≈ 12.3 KB per integration.

But actions/checkout with lfs: true fetches every LFS object in the tree, not just demo files: 203 objects, ~495 MB (largest are multi-MB GIFs under examples/ and assets/, up to 65 MB). That is the real cost driver, and showcase_build.yml has already been paying it for all ~20 integration builds since 2026-06-07 — this PR adds it to the build-check and on-demand-e2e paths. Worth a follow-up look at whether those two need a scoped git lfs pull --include instead of a blanket fetch; flagging rather than solving it here, since it is a pre-existing cost profile.

Proof

Local Docker builds were deliberately NOT used as evidence. A local build smudges LFS from the local checkout and passes regardless of what CI does, so it proves nothing. All evidence above is CI-side or from live prod/staging:

• CI checkout log showing git lfs fetch in the deploy build job (quoted above).
• Live prod + staging HTTP probes returning real magic bytes and exact byte sizes from CI-built images.
• Remote blob sizes read via the LFS-unaware git/trees API.

actionlint on all three edited workflows: 24 findings before, 24 after — none introduced (all pre-existing shellcheck info/style plus the custom depot-* runner label). YAML re-parsed and both ALL_SERVICES blobs re-validated.

CI-side before/after for the build_check path

Same integration (crewai-crews, one of the ten pointer-committed ones), from real CI logs:

BEFORE — run 30132714792, job 89610715113 (branch predating this change):

  lfs: false

No git lfs install, no Fetching LFS objects group. The image was built from a pointer stub.

AFTER — run 30133303667, job 89612372095 (this PR):

  lfs: true
[command]/usr/bin/git lfs version
git-lfs/3.7.1 (GitHub; linux amd64; go 1.24.4)
[command]/usr/bin/git lfs install --local
Git LFS initialized.
##[group]Fetching LFS objects
[command]/usr/bin/git lfs fetch origin refs/remotes/pull/6160/merge

Build Check on this PR: 26 build jobs, 25 success, 0 failure (one still finishing at time of writing).

Prod + staging multimodal cell state

Read from PocketBase (showcase-pocketbase-production / pocketbase-staging-eec0), not from dashboard chip colours.

Red d5 cells: agno, built-in-agent¹, crewai-crews, llamaindex, mastra, ms-agent-python (¹ prod only — green on staging, i.e. flapping).

None of these are asset failures. Every one reports the same signature:

waitForTurnComplete: turn N did not complete within 60000ms (reason=dom-missing, runsFinished=0)

Not is a Git LFS pointer, not the real asset, and not Could not fetch sample … HTTP 404. A scan of 500 prod status records found zero occurrences of any LFS-pointer, sample.png/sample.pdf fetch, or magic-byte error.

The correlation is absent in both directions:

So pointer-committed status does not predict cell state, which is what you'd expect once the deploy path fetches LFS.

Reported separately and loudly: four of those reds — built-in-agent, crewai-crews, llamaindex, ms-agent-python — are long-standing genuine failures with fail_count between 1713 and 2008 on prod, unrelated to this PR and unrelated to agno/mastra's missing files. They share the waitForTurnComplete … dom-missing turn-timeout signature and need their own investigation. Staging shows the same set at fail_count=61.