Verification Gates
Defining the boundaries of trust.
01. What a Gate Is
A gate is a boundary of trust. It is a deterministic threshold that every test must satisfy to be admitted into the knowledge base.
Passing a gate is not an indicator of success or logical completeness. It is merely permission to continue analysis. If a test fails to cross a trust boundary, the engine ceases its reasoning because it can no longer rely on the evidence that test provides.
“A gate determines admissibility, not success.”
02. Why Gates Exist
Standard testing workflows are vulnerable to external pressures. Developers naturally optimize for the convenience of green builds, while management tools optimize for surface-level metrics.
Gates exist to resist both optimizations. They serve as an automated firewall that prevents weak signals, unanchored logic, and "vacuous passes" from contaminating the systemic understanding of the application. They preserve the integrity of the knowledge base by enforcing a rigorous standard of proof.
03. Gate Ordering
The order of verification is linear and cumulative. Each gate validates a specific dimension of trust that later gates rely upon.
Attempting to verify causality when the basic executable shape is invalid, or verifying independent confirmation when no observation exists, results in circular reasoning. Failures are identified at the earliest possible threshold to prevent the accumulation of false confidence.
“If early trust is broken, nothing later can be believed.”
04. The Five Gates
Below is the canonical, ordered gate chain. Each gate is mandatory. If a test fails a gate, it is rejected and does not contribute evidence.
PSR-4 Identity Integrity
Every test class Composer cannot load is invisible to the runner. Identity-integrity failures stop downstream validation because there is nothing left to evaluate.
Admission Criteria
- → Composer PSR-4 autoload resolves the class declared in every test file
- → Namespace declared in the file matches its on-disk path
Mandatory Rejection
- ✖ Classes silently skipped by Composer due to PSR-4 mismatch
- ✖ Filename or directory casing diverges from the namespace
Bootstrap Purity
Tests must not mutate process-global state in ways that bleed between runs. Six rules cover Config, env, INI, timezone, and superglobals.
Admission Criteria
- → Use the `config([...])` helper scoped to the test, never raw `Config::set(...)`
- → No `putenv`, `ini_set`, or `date_default_timezone_set` in test bodies
- → No direct mutation or `unset` of `$_ENV`, `$_SERVER`, `$_GET`, `$_POST`, `$_COOKIE`, `$_REQUEST`, `$_SESSION`
Mandatory Rejection
- ✖ BOOTSTRAP_PURITY_CONFIG_SET — `Config::set(...)` calls
- ✖ BOOTSTRAP_PURITY_PUTENV — `putenv(...)` calls
- ✖ BOOTSTRAP_PURITY_INI_SET — `ini_set(...)` calls
- ✖ BOOTSTRAP_PURITY_TIMEZONE — `date_default_timezone_set(...)` calls
- ✖ BOOTSTRAP_PURITY_SUPERGLOBALS — direct mutation of superglobals
- ✖ BOOTSTRAP_PURITY_SUPERGLOBALS_UNSET — `unset($_ENV[...])` etc.
Mock Discipline
Tests may only mock external services. Mocking the system under test or fakes-by-default of core facades produces tests that prove nothing about real behavior.
Admission Criteria
- → Only mock classes whose namespace lives outside your `App\` PSR-4 root
- → Use Laravel facade fakes (`Event::fake()`, `Queue::fake()`, …) sparingly and only with the corresponding `assert*` calls
Mandatory Rejection
- ✖ FORBIDDEN_MOCK_TARGET — `Mockery::mock(App\…)` or `Illuminate\` / `PHPUnit\` framework internals
- ✖ FACADE_ANTI_GRAVITY — more than three core facades faked or mocked in one test
Act Contract
Each test performs exactly one primary Act. Multi-step tests hide which step actually drives the observable outcome and contaminate the engine's causal map.
Admission Criteria
- → One HTTP request, one job dispatch, one service-under-test method call per test
- → Setup (factories, `actingAs`, fakes) does not count as an Act and may appear before
- → Multi-step flows belong in NON-LEARNING / E2E tests outside the gate scope
Mandatory Rejection
- ✖ ACT_ONCE_RULE — Found N (N ≠ 1) primary Acts in a single test method
Outcome Contract
Every Act must produce an observable outcome the test directly asserts on — HTTP response, DB state change, dispatched job/event, faked-facade assertion, or a meaningful assertion on the Act's return value.
Admission Criteria
- → HTTP: `$response->assertStatus/assertJson/...`
- → Database: `$this->assertDatabaseHas/Missing/Count`
- → Facade fakes paired with their `assert*` calls (`Event::fake()` → `Event::assertDispatched()`)
- → Unit: assertion taking the Act's output as an argument
Mandatory Rejection
- ✖ OBSERVABLE_OUTCOME_REQUIRED — Act present but no qualifying assertion observes its effect
05. Structural Gates
The first layer of verification validates the physical shape and admissibility of a test. It determines whether the test is a valid participant in the system.
Before behavior can be analyzed, the engine must confirm that the test adheres to the required technical constraints and architectural shape. Tests that use non-standard harnesses or bypass framework protocols are rejected immediately. Without a trusted structure, there is no basis for behavioral discussion.
06. Observability Gates
A test must prove its claims through evidence that exists outside its own execution thread. These gates require proof of an effect in reality.
Ephemeral or internal signals—such as the modification of a temporary local variable—are insufficient. Truth must be anchored in state changes that persist or communicate with the system's external environment. If nothing observable changed, the Auditor assumes that nothing was verified.
07. Causality Gates
Observation alone is not sufficient for proof. The engine must be able to attribute the observed effect to the specific catalyst introduced by the test.
These gates enforce the link between action and result. If an effect existed before the test began, or if it could have been produced by an unrelated background process, the link is considered unanchored. Evidence without a provable cause is noise.
08. Strictness Gates
One point of confirmation is fragile. Strictness gates require multiple independent angles of verification to corroborate a behavioral truth.
These gates are not designed to increase the vanity of code coverage metrics. Instead, they increase the depth of the proof. By demanding independent confirmation of critical side effects, the engine ensures that a "pass" is a robust verification of business value rather than a technical coincidence.
09. What It Means to Fail a Gate
A gate failure is a request for evidence.
It is not a bug report, a judgment of developer skill, or an accusation of incorrect code. It is the engine stating that it has reached a boundary where trust is no longer earnable from the current test shape.
Verification failure is non-negotiable. SATE-Laravel will not weaken a gate or accept a "soft pass." Weakening gates to accommodate unanchored tests only serves to corrupt the overall integrity of the knowledge base.
Stop arguing with the failure. Start providing the missing evidence.