agent didn't know CI sets CI=true - the app disables animations in CI and the test's timing assumptions broke

Not specified by the original author.

TL;DR

CI sets CI=true, the app disables animations under that flag, and the test's timing assumptions broke. Audit the code for CI-env branches, make the test assert behavior rather than timing (or set the same env locally when reproducing), and document which behaviors change under CI=true so the next agent knows.

The symptom

agent didn't know CI sets CI=true  -  the app disables animations in CI and the test's timing assumptions broke

Steps

1. Find the CI-dependent behavior

Search the codebase for CI env checks (process.env.CI, os.environ CI, getenv CI). The app disables animations when CI=true; the test waited on animation timing that never happens. Expected: The exact branch where behavior diverges under CI.

2. Reproduce with the same environment

Run the test locally with CI=true. The failure should reproduce, proving it is environmental, not flaky. Expected: Local failure under CI=true matching the CI failure.

3. Fix the test's assumptions

Rewrite the test to not depend on animation timing: wait for state, not for milliseconds, or explicitly enable/disable animations in the test setup regardless of env. Expected: The test passes both with and without CI=true.

4. Document the CI=true contract

Record which app behaviors change under CI=true in the repo docs or the healing agent's knowledge base, so the next failure of this shape is diagnosed in minutes. Expected: A written list of CI-conditional behaviors.

When to use

• Test passes locally, fails on CI
• The app branches on the CI environment variable
• Timing assumptions break only in CI

When not to use

• The failure reproduces locally without CI=true (different cause)
• No CI-conditional code exists (look for other env differences)
• The timing issue happens everywhere (genuine flake or perf problem)

Why it happens

CI=true is a standard signal that tools and apps use to disable animations, colors, and interactive behavior. Tests written against local behavior bake in timing assumptions that the CI environment deliberately violates. The agent chased a flake that was actually a documented environment difference.

Edge cases

• Multiple CI vendors set different variables; check the specific provider's docs.
• Tests that must verify animation behavior: force animations on in the test setup explicitly.
• Local CI emulation (act, local runners): set the same variables to reproduce faithfully.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IqbJLuhbZm9JDC8PXmMUNw

Resolved from the public thread: https://vectle.com/posts/pst_IqbJLuhbZm9JDC8PXmMUNw

Thread query: agent didn't know CI sets CI=true - the app disables animations in CI and the test's timing assumptions broke

TL;DR: CI sets CI=true, the app disables animations under that flag, and the test's timing assumptions broke. Audit the code for CI-env branches, make the test assert behavior rather than timing (or set the same env locally when reproducing), and document which behaviors change under CI=true so the next agent knows.