E2E Audit

Existing tests

1. Resolve every concrete suite. For directories, find all *_test.go files. Follow shared suites, setup code, helpers, and provisioners rather than judging files in isolation.
2. Read each test and subtest, including setup, gating, environment updates, and cleanup. Inspect the production code it exercises before deciding that an assertion can be tested at a lower level.
3. Inventory the observable claims in each test. Include implicit claims from setup and lifecycle operations, and group checks that cover the same contract.
4. For each assertion, state the failure it catches, identify the smallest environment that preserves that failure, note equivalent lower-level coverage, and classify it using the principle above.
5. Give the suite-level verdict:
   • If any assertion needs the deployed Agent boundary, the suite remains E2E; name the assertion and boundary that determine this verdict.
   • If none does, recommend an integration or unit test as appropriate.
6. Recommend duplicating suitable assertions at a lower level when that would provide faster PR feedback, more deterministic failures, or easier debugging, even if the suite initially remains E2E.
7. After accounting for that lower-level coverage, identify the failure modes and real boundaries that only the E2E test preserves. If nearly all material assertions are duplicated and no meaningful E2E-only boundary remains, recommend removing the E2E test. Weigh its residual value against runtime, provisioning, flakiness, and maintenance cost; do not assume all cost is paid only once at suite setup.
8. When reviewing several suites, briefly note redundant provisioners or equivalent coverage that could be consolidated.

For large reviews, inspect files in parallel if possible, then verify and synthesize the results.

Output

Use one of these verdicts:

• E2E justified
• Should be an integration test
• Should be a unit test

For proposed behavior, classify each expected assertion and return an overall verdict with a short reason. For existing tests, classify each material assertion and return one verdict per concrete suite, naming the assertion and boundary that determine it. State what the E2E test uniquely validates after accounting for lower-level coverage, or say that no material E2E-only boundary remains. When several assertions differ, use a concise table with these columns: assertion, failure caught, smallest environment, and classification. Add only material uncertainty, lower-level candidates, or consolidation opportunities.

Examples

Input: Verify that installing the Agent package creates a running service with the expected permissions and that data reaches fakeintake after a reboot.

Output: E2E justified — The package installation, service lifecycle, permissions, reboot, and forwarding path are the behavior under test; a lower-level test would not preserve those deployed-system boundaries.

Input: Verify that the assembled Agent components transform a payload and send it to a local fakeintake.

Output: Should be an integration test — A locally assembled component graph and fakeintake preserve the component wiring and payload boundary without provisioning remote infrastructure.

Input: Verify that the configuration parser rejects a negative timeout and applies the default when the field is absent.

Output: Should be a unit test — This is isolated parsing and validation logic that does not require a real component graph, process, or external dependency.

Do not propose implementation changes unless the user asks for them.