The gate added in the previous commit would have failed on a clean checkout.
The Strands TypeScript integration sits outside the pnpm workspace on purpose:
its agent process resolves openai and the Strands SDK from its own
node_modules, which the Dockerfile installs with npm ci. The workflow ran only
the repo-root pnpm install, so two of the four test files could not resolve
their imports. It passed locally only because that directory already existed on
this machine. Reproduced by moving it aside (2 files fail), then confirmed the
workflow's own steps green it again (16 tests pass).
The job now installs the agent package the same way the Dockerfile does, and
runs the vitest config that already lives beside those tests rather than a
second config layered above them, so CI runs exactly what `npm test` in that
directory runs. The path filters narrow to the sources the run actually covers,
so a PR touching an unrelated integration no longer collects a green check from
a job that exercised none of its code.
The showcase integrations sit outside the pnpm workspace, so nx never
discovers them and the harness unit workflow does not cover them. Their Python
tests are already gated by showcase_validate.yml, but nothing anywhere ran
vitest under showcase/integrations: four test files in the Strands TypeScript
agent, including the one this branch adds for the resume envelope, could fail
indefinitely without CI noticing.
A small config at showcase/integrations/vitest.config.ts gives those tests one
home, driven by the monorepo's own vitest so no integration has to carry a test
dependency into its Docker image. Its include list is an allowlist rather than
a wildcard: most integrations' existing tests resolve imports through their own
Next.js path aliases and only run under their own config, so sweeping them all
in would fail on arrival. Adding an integration to the list means first making
its tests runnable from the repo root.
The workflow runs that config on pull requests touching the integration agent
sources or their tests. It does not pass --passWithNoTests, so an include list
that stops matching fails the job rather than reporting an empty success, and
it interpolates no discovered filenames into a shell command, since a fork
controls the file names in this tree.