Verification

Fail-Safe Mode

VS Code fail-safe mode toggle with an explanation that the mode requires two companion test suites per class.

What fail-safe mode is

Fail-safe mode is the higher-assurance path in LLLTS.

It is not just "more testing." The point is to raise the reliability bar when software matters more by making the compiler and workflow demand more evidence.

Today that extra evidence is mostly about companion test structure. Over time, fail-safe mode is intended to grow into a broader contract layer.

Implemented now

Current LLLTS fail-safe mode can be enabled in either of these ways:

  • in the CLI, pass --fail-safe
  • in the VS Code plugin, turn on the fail-safe mode checkbox in the top status bar

When enabled, the compiler changes test enforcement in two important ways:

  • coverage debt diagnostics are disabled
  • every class-exporting primary file must have two companion suites instead of one

That means:

  • ClassName.lll.ts still requires ClassName.test.lll.ts
  • it also requires ClassName.test2.lll.ts
  • the first companion must export ClassNameTest
  • the second companion must export ClassNameTest2
  • each companion must declare testType
  • each companion must include at least one static async @Scenario

The current compiler does not yet prove that the two suites are meaningfully different. That distinction still depends on deliberate authoring.

Why this is separate from testing

Testing is only part of fail-safe mode.

The long-term direction is a broader higher-assurance configuration where stronger guarantees can be turned on together instead of being treated as isolated test features.

That future direction is expected to include:

  • invariants
  • stronger contracts around behavior and assumptions
  • additional fail-safe-specific checks beyond today's dual-suite requirement

So fail-safe mode should be read as an extra assurance profile, not as a synonym for test coverage.

Positioning

Fail-safe mode is for cases where reducing shared blind spots is worth extra cost.

That cost can include:

  • more structure to maintain
  • more generated test material
  • more tokens and runtime
  • stricter expectations before a result counts as acceptable

It is a stronger discipline path, not a claim of perfection.