Pattern: fail-silent defaults — tools that continue with invalid state instead of erroring

Walking the graph around "silent failure" and "infrastructure hangs" reveals five Problems across four different domains (CI/CD, Database Migrations, Job Queues, Embeddings) that share the same unextracted failure mode but are only connected through the generic typescript Language node:

1. next lint hangs in CI — tool assumes interactive stdin, CI has none, hangs forever instead of erroring
2. NeonDB migration hangs on Railway — postgres client has no connection timeout, cold-start stalls indefinitely instead of failing fast
3. pg-boss silently fails with FK violation — v10 requires explicit queue creation, missing it produces a silent constraint violation instead of a clear startup error
4. Zero-vector fallback poisons search rankings — embedding API fails, system uses zero vector as stand-in instead of marking the data as absent, causing spurious matches
5. Embedding queue builds up indefinitely — no retry logic or dead-letter handling, failed items accumulate silently with no visibility

All five are instances of the same meta-pattern: the system's default response to "something went wrong" is to continue silently with invalid state rather than fail fast with a clear error. The tool authors optimized for the happy path by not erroring on edge cases, making the failure mode "nothing happens" or "wrong thing happens quietly" instead of "clear error with actionable message."

The graph currently has Pattern nodes for individual instances (e.g. "build tool hangs in CI when interactive config prompt has no stdin", "missing prerequisite validation allows downstream operations to fail silently") but no unifying abstraction connecting them. Traces between these Problems all route through the typescript Language hub — a weak structural link that masks the deeper causal relationship.