The Torture Chamber 🔩 — archetype-based adversarial testing for ha-mcp tools

[Patch76]

I've been thinking about test coverage for ha-mcp tools and wanted to open a discussion
before writing a single line of code. @kingpanther13 @sergeykad — would love your take.

The problem

We have 92+ tools. Writing an individual test scenario for each one doesn't scale —
and the existing E2E suite covers happy paths well, but adversarial inputs (bad entity
IDs, wrong types, injection attempts, double-deletes, concurrent calls) are largely untested.

The idea: group by input archetype, not by domain

Looking at the tool surface, I count 9 input archetypes that recur across all domains.
One reusable test suite per archetype covers the majority of tools without per-tool work:

#	Archetype	Examples	Risk
A1	Parameterless	ha_get_overview, ha_check_config	Low
A2	Optional ID → list or detail	ha_get_zone, ha_config_get_label, ha_get_blueprint	Low
A3	Required entity_id	ha_get_state, ha_get_entity	Low
A4	Query + filters + pagination	ha_search_entities, ha_deep_search, ha_hacs_search	Low
A5	Structured config (create)	ha_config_set_automation, ha_config_set_helper	Medium
A6	ID + structured config (update)	ha_config_set_automation(identifier=…), ha_set_entity	Medium
A7	Destructive	ha_config_remove_automation, ha_delete_config_entry	High
A8	System ops	ha_restart, ha_backup_restore, ha_bulk_control	High
A9	Chained / stateful	ha_get_operation_status(operation_id=…)	Medium

Torture dimensions (orthogonal to archetypes)

Each archetype gets hit from these angles:

• Boundary inputs — limit=0, offset > total, "", null, 10k-char strings
• Type confusion — str where list expected, int where bool expected
• Injection — Jinja2 ({{ 1/0 }}), null bytes, Unicode edge cases
• Concurrency — parallel calls on the same entity; simultaneous create + delete; ha_bulk_control race vs. individual state write. This matters: a misbehaving LLM will fire concurrent calls.
• Rate limiting / exhaustion — rapid-fire on ha_deep_search, ha_backup_create; does the server degrade gracefully or crash?
• Idempotency — same create call twice → no duplicate, same result
• CRUD cycle — create → read → update → delete → verify gone
• Stale references — delete an entity, then reference it in an automation config
• Error shape — is every error a proper create_error_response? No raw exceptions?
• Isolation — A7 + A8 need a throwaway HA instance (Docker Compose + snapshot/restore)

Starting point I'd suggest

A3 + A4 first — purely read-only, no side effects, high tool count. Quick wins to validate
the harness pattern before touching anything with state or side effects.

A rough sketch (pseudocode — adapting to actual test client API):

@pytest.mark.parametrize("entity_id,expect_success", [
    ("sensor.does_not_exist", False),
    ("",                       False),
    ("sensor.",                False),   # malformed
    ("light.living_room",      True),
])
async def test_get_state_input_variants(client, entity_id, expect_success):
    result = await client.call_tool("ha_get_state", {"entity_id": entity_id})
    assert result["success"] == expect_success
    if not expect_success:
        # Must use create_error_response — no raw exception string
        assert "error" in result or result.get("success") is False

Open questions — in order of difficulty

1. A7/A8 isolation in CI — is Docker Compose + HA container + snapshot-per-test-class feasible, or does the CI setup need to be built first? Happy to explore this, but it depends on what already exists.
2. Scope — upstream contribution to tests/src/e2e/ or tests/torture/, or a standalone harness users run against their own instance? Both have merit.
3. Concurrency harness — asyncio.gather() suffices for simple races; is there appetite for a more structured concurrency test layer?
4. Output validation depth — schema check (keys + types correct) or semantic check (state actually matches HA reality)?
5. feat: add ha_manage_custom_tool — sandboxed code execution escape hatch #854 (ha_manage_custom_tool) — if it lands, it'll need its own class: sandbox-escape attempts, code injection, resource exhaustion. Worth designing upfront.

Happy to draft a first PR for A3+A4 if the direction makes sense.

[kingpanther13]

We already have BAT testing / UAT, this sounds like something that should be a part of BAT testing and not necessarily part of e2e. BAT/UAT are run by users/devs individually, I believe we currently have 13 "stories" set up.

[sergeykad]

Thanks for the thorough write-up. A few thoughts.

ha-mcp serves a single household. The LLM client is the only caller — there's no adversarial traffic, no untrusted input, no multi-tenant contention. The threat model doesn't justify a concurrency torture suite or injection fuzzing harness.

Most of this proposal is input validation. The archetype taxonomy and torture dimensions are a useful way to think about it, but the actual test mechanics are straightforward: parametrize bad inputs, verify structured error responses. That fits naturally as an extension of our existing E2E tests rather than a separate framework.

Error format consistency is already enforced. We use ast-grep rules in a commit hook to verify error paths use create_error_response — so the audit portion is covered.

What I'd find valuable:

• Parametrized negative-input cases in the existing E2E suite (nonexistent entities, malformed configs, empty strings)

What I'd skip:

• A separate tests/torture/ directory or standalone harness
• Concurrency race testing and rate-limit exhaustion scenarios
• The full 9×10 archetype-by-dimension matrix

@kingpanther13 good point about BAT, though I see BAT as testing how well LLMs work with our tools (descriptions, context, workflows), while input validation tests the tools themselves. E2E is the better home for this.

Could you point to specific bugs or regressions this would have caught? That would help ground the scope in real problems rather than theoretical coverage.

[Patch76]

Fair points across the board — and the ast-grep enforcement on
create_error_response is something I'd genuinely missed. That does cover
the error-shape audit angle I was thinking about.

---

What ast-grep doesn't cover is the input side: whether a bad input
reaches an error path at all, or silently returns success=True with
degraded output:

# Does this return a structured error, or an empty results list with success=True?
ha_get_state(entity_id="sensor.")          # malformed
ha_search_entities(query="", limit=0)     # boundary input
ha_config_set_helper(name="")             # empty required field

That's the narrower gap I'd find useful — a handful of parametrized cases
in the existing E2E suite, nothing more.

No separate harness · no concurrency · no full matrix

If even that feels like over-engineering here, totally understood —
happy to leave it as-is. 🙏

[kingpanther13]

I think that's fair to look into. We recently had a lot of issues with false success, and I just went thru a PR that sought to eliminate the remaining false successes, but obviously it's impossible to catch everything. I've also noticed Claude will "typo" things pretty frequently ... My MCP in Claude has "cloudflared" in the name and occasionally Claude will call it "cloudflUred" or "cloudflaredd" for no particular reason (I have never used those names before so no idea where it even got them) which causes the tool to fail. I ask it why this happened and it just says "oops, I made a typo" which makes no sense. It catches itself in those instances and tries again with proper name, but this tells me it's a certainly possible for it to hallucinate any type of input. So yeah, tests to catch intentionally malformed inputs to see if errors are returned properly sounds like a decent idea.

[sergeykad]

@Patch76 Sounds good — a focused PR adding parametrized negative-input cases to the existing E2E suite is welcome.

A few guidelines:

Start small. Pick one archetype (A3 or A4) and cover 5-6 tools in a single PR. A PR touching all 92+ tools will be hard to review, and any repeated mistakes get multiplied across the whole suite. Better to get the pattern right on a small scope first.

Keep it tight. More tests isn't always better — each one adds CI time. Before adding a test, ask: does this hit a different branch in the code, or just a different spelling of the same input? 2-3 cases per tool (malformed, empty, nonexistent) rather than exhaustive permutations.

Check existing coverage. Some negative paths may already be tested in the E2E suite. No point duplicating.

[Patch76]

Following up — first PR is up:

➡️ #924 — test(e2e): add parametrized negative-input tests for A3 tools

Covers ha_get_state and ha_get_entity with 3 parametrized input cases + one design-behaviour doc test. Kept to A3 only and two tools for the first round, exactly as suggested. Happy to adjust scope or pattern based on feedback there.

[Patch76]

Following up on the A3 thread — #924 just landed its final revision and I've been mapping what's left in the archetype before opening another PR.

---

Where #924 ended up

After sergeykad's review I went back and verified the existing coverage properly — both unit and E2E layers — instead of relying on my initial E2E-only scan. The corrected picture was: 3 of 4 original tests were duplicates with hard assertions already in place (test_state.py, test_entity_management.py). The only genuinely uncovered paths for ha_get_state were "" (plain-text 404, distinct client parse path), "sensor." (standard JSON 404), and [] (pre-flight validation, no network I/O) — which is exactly what the final 39-line version covers.

That process also gave me a cleaner methodology for the next round: check the source code to identify distinct failure paths first, then verify coverage for each path across both layers before writing anything.

---

What I found for the remaining A3 tools

Applying the same methodology to ha_get_history and ha_get_automation_traces:

ha_get_history

test_history.py has solid happy-path coverage. One test exists for a nonexistent entity (test_get_history_nonexistent_entity), but it uses only parse_mcp_result + logging — no hard assertion. This connects to something @kingpanther13 flagged earlier in this thread: ha_get_history("sensor.nonexistent") returns success=True with an empty states list, not an error. That's by design, but it's exactly the kind of silent non-failure that's hard to catch. The negative-input paths are otherwise untested:

Input	What happens	Layer	Existing hard coverage
""	valid_entity_id("") = False → HA WebSocket rejects it	no pre-flight — reaches WS	none
[]	caught by MCP pre-flight, no WebSocket call	validation only	none

The valid_entity_id check lives in homeassistant/components/history/websocket_api.py — the WS handler validates each entity ID against the <domain>.<object_id> regex before querying the recorder. Verified locally:

valid_entity_id("")        # False → WS rejects → error response
valid_entity_id("sensor.") # False → WS rejects → error response
valid_entity_id("sensor.nonexistent") # True → WS succeeds, empty result

These two paths ("" and []) are structurally different from each other and from the ha_get_state equivalents: "" is rejected at the WebSocket layer (no pre-flight guard in the MCP), while [] is caught by MCP pre-flight before any network I/O. Full-text search across all 121 test files confirms no existing coverage for either.

One note relevant to #911: that PR introduces test_tools_history.py with two unit tests, but they cover exception-suggestion branching for source="statistics" vs "history" only — no negative entity ID inputs. No overlap with what I'm proposing here, and the validation logic for entity_ids is unchanged by #911's refactoring (verified in the diff).

---

ha_get_automation_traces

test_traces.py covers create/trigger/verify and empty-traces-with-diagnostics. The domain-prefix guard in the tool is untested:

if automation_id.startswith("automation."):
    domain = "automation"
elif automation_id.startswith("script."):
    domain = "script"
else:
    raise_tool_error(...)  # rejected before any WebSocket call

Input	What happens	Existing hard coverage
"sensor.some_entity"	rejected by MCP, no WS call	none

"" hits the same guard — one test covers both shapes.

---

Proposed scope

Three tests across two tools, all in the existing E2E suite:

1. ha_get_history(entity_ids="") — bypasses MCP pre-flight, rejected by HA's WebSocket validator
2. ha_get_history(entity_ids=[]) — caught by MCP pre-flight, no WS call
3. ha_get_automation_traces(automation_id="sensor.some_entity") — wrong domain prefix, rejected before WS call

Happy to hold off until #924 and/or #911 land first if that's preferable.

[Patch76]

Following up on the A3 thread — a correction to the #924 methodology, and a proposal for A4.

---

Correction from #924

sergeykad's review of #924 surfaced a methodology error worth documenting before the next PR.

The analysis behind #924 claimed that ha_get_state("") hits a "distinct client parse path" (plain-text 404 vs JSON 404). That's wrong. rest_client.py:126-134 handles both identically: response.json() is attempted, plain text falls back to {"message": response.text}, and HomeAssistantAPIError(status_code=404) is raised either way. The plain-text/JSON distinction is server-side only. The client code path for "" and "sensor." is identical.

The corrected coverage picture for ha_get_state:

Input	Genuinely new coverage
[]	Yes — VALIDATION_FAILED pre-flight, not hard-asserted elsewhere
""	No — same REST path as "sensor.", already soft-covered in test_network_errors.py:64
"sensor."	No — same path as ""

So the only case in #924 with genuinely new coverage is []. The string cases were duplication of existing (soft) tests and each other.

The methodology fix going forward: verify rest_client.py (or the WS client) before claiming two inputs hit "distinct parse paths". Source-level equivalence has to be verified, not inferred from server-side behavior.

---

Proposed scope: A4 · ha_search_entities

ha_search_entities has solid coverage for the domain_filter listing path. Two paths are untested and structurally distinct from each other and from the existing suite.

limit — no lower-bound guard

Only offset is coerced with min_value=0 (line 212). limit flows directly into slice operations:

limit=0  → filtered_entities[0:0]   → empty list, success=True, count=0
limit=-1 → filtered_entities[0:-1]  → all but last entity, success=True

Both return success=True. limit=-1 produces subtly wrong results with no error signal. Neither is tested anywhere.

query="" without domain_filter

Without domain_filter, the empty-query branch at line 332 doesn't activate. The call falls through to _exact_match_search, where "" in entity_id.lower() is always True — every entity matches. search_type="exact_match", success=True. Behavior is unspecified and untested (the docstring only documents query="" with domain_filter).

test_network_errors.py already covers this softly (~line 230), so this is in the same position as ha_get_state("") above — existing soft coverage. Whether a hard assertion on search_type adds value is a judgment call.

Proposed tests — tests/src/e2e/tools/test_search_entities.py (alongside existing tests):

#	Input	Path	What it proves
1	ha_search_entities(query="light", limit=0)	slice [0:0]	count=0, success=True; documents boundary
2	ha_search_entities(query="light", limit=-1)	slice [0:-1]	Error or documented degraded behavior
3	ha_search_entities(query="", limit=5)	_exact_match_search empty string	All entities match; hard-asserts current behavior

Test 3 is the weakest — happy to drop it if soft coverage is considered sufficient.

Happy to wait until #924 and/or #911 land before opening the next PR.

[sergeykad]

The limit=-1 finding in your A4 analysis is a genuine issue — filtered_entities[0:-1] silently drops the last result with no error signal. If you're up for it, include a fix (validation guard or clamp to 1) alongside the test in your A4 PR.

The ha_get_history and ha_get_automation_traces gaps look well-researched and genuinely uncovered. Go ahead with a PR for those once #924 is closed.

For the A4 scope: limit=0 and limit=-1 are worth testing, but the fix for -1 should come first. query="" without domain_filter is the weakest case — soft coverage exists and the behavior, while surprising, isn't broken.

[Patch76]

Closing the loop on this discussion — here's what came out of it.

---

PR	Merged	What
#924	closed, not merged	A3 first attempt
#946	2026-04-11	fix ha_search_entities limit guard
#954	2026-04-11	fix ha_deep_search limit + offset guard
#945	2026-04-12	tests ha_get_history + ha_get_automation_traces
#957	2026-04-12	test ha_get_zone nonexistent id
#958	2026-04-12	test ha_config_get_label nonexistent id

---

#924 (closed, not merged) — first A3 attempt. Revealed that 3 of 4 proposed tests duplicated existing hard assertions elsewhere in the suite. Closed in favor of a cleaner scope — but the failure was the most useful outcome: verifying coverage across both unit and E2E layers before writing tests changed the methodology for everything that followed.

#946 (merged 2026-04-11) — silent data-corruption fix in ha_search_entities: limit=-1 and limit=0 produced wrong results with success=True. One-line guard via coerce_int_param(min_value=1), two hard-asserting regression tests.

#954 (merged 2026-04-11) — same root cause in ha_deep_search: limit and offset both unguarded, same fix pattern as #946.

#945 (merged 2026-04-12) — negative-input tests for ha_get_history and ha_get_automation_traces: empty string bypassing MCP pre-flight and hitting the HA WebSocket validator, empty list caught before any network I/O, wrong domain prefix rejected client-side. Three structurally distinct paths, all genuinely uncovered before.

#957 (merged 2026-04-12) — one hard-asserting test for ha_get_zone with a nonexistent zone_id (client-side filter, no WS call).

#958 (merged 2026-04-12) — same for ha_config_get_label, plus a survey of adjacent A2 tools to confirm no further gaps.

---

Thanks again for the direction that shaped this — the archetype framing made it straightforward to identify where real gaps existed versus where coverage only looked missing.

I learned a lot out of it ... and my Claude too 🛩️

To be continued ...

[Patch76]

Following up with A7 — first PR is up:

➡️ #987 — test(e2e): add negative-input tests for A7 destructive tools

Three structurally distinct failure paths, source-verified before writing:

Test	Tool	Input	Source path
test_remove_automation_nonexistent	ha_config_remove_automation	nonexistent identifier	create_resource_not_found_error → raise_tool_error
test_remove_automation_double_delete	ha_config_remove_automation	second remove after successful delete	same 404 branch — idempotency failure
test_delete_config_entry_nonexistent_confirmed	ha_delete_config_entry	confirm=True, nonexistent entry_id	exception_to_structured_error(raise_error=True) → ToolError

The existing CRUD lifecycle tests verify deletion via ha_config_get_automation — neither calls ha_config_remove_automation on an already-absent identifier. The confirm=True + nonexistent path for ha_delete_config_entry was similarly unexercised.

Survey of remaining A7 tools:

Tool	nonexistent-remove test?
ha_config_remove_helper	✅ already covered (test_helper_delete_nonexistent)
ha_remove_zone	✅ already covered
ha_config_remove_script	❌ gap (verify-gone tests get_script, not remove_script)
ha_config_remove_area	❌ gap
ha_config_remove_floor	❌ gap
ha_config_remove_label	❌ gap (nonexistent test targets get_label)
ha_config_remove_category	❌ gap
ha_config_delete_dashboard	❌ gap
ha_config_remove_calendar_event	❌ gap
ha_remove_device	❌ gap

Happy to follow up on the remaining gaps in a subsequent PR if the pattern in #987 looks right.

[Patch76]

Correction to the A7 survey in my previous comment — I checked more carefully against the actual test files.

Revised picture:

Tool	Status
ha_config_remove_automation	✅ #987
ha_delete_config_entry	✅ #987
ha_config_delete_dashboard	✅ already covered (test_delete_nonexistent_dashboard, hard assert on RESOURCE_NOT_FOUND)
ha_remove_device	✅ already covered (test_remove_device_nonexistent, hard assert)
ha_config_remove_label	✅ already covered (test_delete_nonexistent_label, hard assert)
ha_config_remove_category	⚠️ exists but soft only — no assert not success, just if/else logging
ha_config_remove_calendar_event	⚠️ exists but soft only — no hard assert on failure
ha_config_remove_area	❌ gap
ha_config_remove_floor	❌ gap
ha_config_remove_script	❌ gap

So the remaining work is smaller than I thought: 3 hard gaps + 2 soft-only tests worth hardening. Plan is to address these in 1–2 follow-up PRs after #987 lands.

[Patch76]

Closing the loop on A7 — #987 landed today 08e6e6bb
Rechecking my A7 survey from the previous comment against master, I need to correct two entries I miscategorized:

Tool	Master status	Evidence
ha_config_remove_automation	✅ hard	#987, RESOURCE_NOT_FOUND assert
ha_delete_config_entry	✅ hard	#987, ToolError assert
ha_config_delete_dashboard	✅ hard	pytest.raises(ToolError) + error["code"] == "RESOURCE_NOT_FOUND"
ha_remove_device	✅ hard	assert not success + error code check
ha_config_remove_label	✅ hard	assert not delete_data.get("success")
ha_config_remove_helper	⚠️ soft (corrected)	test_helper_delete_nonexistent exists but only if/else-logs both outcomes — no assert
ha_remove_zone	❌ gap (corrected)	test_zone_get_nonexistent covers ha_get_zone, but there's no negative-input test for ha_remove_zone itself
ha_config_remove_category	⚠️ soft	if/else-logs, no assert
ha_config_remove_calendar_event	⚠️ soft	same pattern
ha_config_remove_area	❌ gap	only appears in cleanup calls
ha_config_remove_floor	❌ gap	no test references found
ha_config_remove_script	❌ gap	only happy-path cleanup

So the actual remaining A7 work is larger than my previous comment suggested: 4 hard gaps (remove_area, remove_floor, remove_script, remove_zone) + 3 soft-only tests worth hardening (remove_helper, remove_category, remove_calendar_event).

Methodology note for myself: I had relied on test names (test_helper_delete_nonexistent, test_remove_device_nonexistent) as existence markers without opening the files. Same failure mode as the rest_client.py check from #924 — inference without source verification. I'll read the assertion body, not just the name, before calling something covered.

For context, the archetype-PR series that grew out of this thread:

Archetype	Merged PRs
A3 (required entity_id)	#945, #957, #958
A4 (query + filters)	#946, #954 (fixes), #945 (tests)
A5 (structured create)	#982
A6 (id + update)	#983
A7 (destructive)	#987

Flagging the corrected gap list here as a record. No action from my side until there's appetite for a follow-up — happy to leave it open.

[Patch76]

A7 follow-up landed — #1047 (c701c99a), 2026-04-24.

Source-verification before authoring shifted the picture from my 17.04 survey:

Tool	17.04 status	Now	Note
ha_config_remove_area	❌ gap	✅ #1047	new test_remove_area_nonexistent, SERVICE_CALL_FAILED
ha_config_remove_floor	❌ gap	✅ #1047	new test_remove_floor_nonexistent, same path
ha_config_remove_category	⚠️ soft	✅ #1047	if/else-log → explicit error-code + message asserts
ha_config_remove_script	❌ gap	✅ already hard	scripts/test_lifecycle.py call_tool_failure(..., expected_error="not found")
ha_remove_zone	❌ gap	✅ already hard	zones/test_lifecycle.py, call_tool_failure on nonexistent zone_id
ha_config_remove_helper	⚠️ soft	🟡 design-blocked	dual-success via method="already_deleted" — hard assert not success would break the legitimate idempotent path. Needs design call on idempotent-success vs. error semantics before hardening.
ha_config_remove_calendar_event	⚠️ soft	🟡 scope-blocked	soft test legitimately handles shared-calendar UID collisions. Hardening needs a factory-created deletable event — out of scope for test-only PR.

So A7 is functionally closed: 5 of 7 hard, 2 left in flight with documented blockers (not silent gaps).

Updated archetype state:

Archetype	Merged PRs
A3	#945, #957, #958
A4	#946, #954 (fixes), #945 (tests)
A5	#982
A6	#983
A7	#987, #1047

Same methodology lesson held up: reading the assert body (not just the test name) caught the four false-gap entries before they became another #924-style retraction.

[Patch76]

Wrap-up — tracing each archetype to its current disposition.

State at 2026-05-23:

#	Archetype	Disposition
A1	Parameterless	organically covered (happy path across 8+ test files for ha_get_overview, ha_check_config in test_system_tools.py). Negative-input concept degenerate — no parameters to malform.
A2	Optional ID → list / detail	closed — #957, #958 + adjacent organic coverage (test_get_blueprint_not_found, test_list_blueprints_invalid_domain, test_get_nonexistent_category).
A3	Required entity_id	closed — #945.
A4	Query + filters + pagination	closed — #946 + #954 (silent-corruption fixes) + #945 (tests).
A5	Structured config (create)	closed — #982.
A6	ID + structured config (update)	closed — #983.
A7	Destructive	functionally closed — #987 + #1047. Two documented design / scope blockers remain (see below).
A8	System ops	substantively covered — ha_restart (test_system_tools.py:76, :108), ha_bulk_control (test_bulk.py:247, :309), ha_backup_create + ha_backup_restore validation in HAOS E2E test_backup.py (the original "skip on
missing-default-password" blocker per #366 was resolved when HAOS infrastructure added set_default_backup_password at session start, tests/src/e2e/conftest.py:1329). The discussion's original isolation question — throwaway HA instance — is answered at
session level by the HAOS qcow2 per CI run.
A9	Chained / stateful	closed — three negative cases in test_operation_status.py (test_single_operation_id_invalid, test_list_operation_ids_empty, test_list_operation_ids_invalid).

A7 blockers — filed as successor issues:

• ha_delete_helpers_integrations — fallback_used="already_deleted" short-circuit produces success=True for a nonexistent target (tools_integrations.py:1718-1732); hardening needs a decision on whether the idempotent dual-success is a permanent contract
  or a transitional artifact. Filed as [FEATURE] decide ha_delete_helpers_integrations idempotent dual-success contract #1412. (Correction to my 2026-04-25 comment, which cited this tool incorrectly as ha_config_remove_helper.)
• ha_config_remove_calendar_event — shared-calendar UID collisions make a hard not success assertion unsafe on the existing test_delete_calendar_event; hardening needs a factory-created deletable event. Filed as [FEATURE] harden test_delete_calendar_event with factory-created deletable event #1413.

A1: behavior under degraded HA states (down, restarting, partial integration failures) belongs in chaos-engineering scope, not input-archetype scope. Defensibly out.

Closing as resolved. 8 of 9 archetypes closed or substantively covered; 1 defensibly skipped (A1). The two A7 follow-ups now have focused homes in #1412 and #1413. Wrap-up — tracing each archetype to its current disposition.

State at 2026-05-23:

#	Archetype	Disposition
A1	Parameterless	organically covered (happy path across 8+ test files for ha_get_overview, ha_check_config in test_system_tools.py). Negative-input concept degenerate — no parameters to malform.
A2	Optional ID → list / detail	closed — #957, #958 + adjacent organic coverage (test_get_blueprint_not_found, test_list_blueprints_invalid_domain, test_get_nonexistent_category).
A3	Required entity_id	closed — #945.
A4	Query + filters + pagination	closed — #946 + #954 (silent-corruption fixes) + #945 (tests).
A5	Structured config (create)	closed — #982.
A6	ID + structured config (update)	closed — #983.
A7	Destructive	functionally closed — #987 + #1047. Two documented design / scope blockers remain (see below).
A8	System ops	substantively covered — ha_restart (test_system_tools.py:76, :108), ha_bulk_control (test_bulk.py:247, :309), ha_backup_create + ha_backup_restore validation in HAOS E2E test_backup.py (the original "skip on
missing-default-password" blocker per #366 was resolved when HAOS infrastructure added set_default_backup_password at session start, tests/src/e2e/conftest.py:1329). The discussion's original isolation question — throwaway HA instance — is answered at
session level by the HAOS qcow2 per CI run.
A9	Chained / stateful	closed — three negative cases in test_operation_status.py (test_single_operation_id_invalid, test_list_operation_ids_empty, test_list_operation_ids_invalid).

A7 blockers — filed as successor issues:

• ha_delete_helpers_integrations — fallback_used="already_deleted" short-circuit produces success=True for a nonexistent target (tools_integrations.py:1718-1732); hardening needs a decision on whether the idempotent dual-success is a permanent contract
  or a transitional artifact. Filed as [FEATURE] decide ha_delete_helpers_integrations idempotent dual-success contract #1412. (Correction to my 2026-04-25 comment, which cited this tool incorrectly as ha_config_remove_helper.)
• ha_config_remove_calendar_event — shared-calendar UID collisions make a hard not success assertion unsafe on the existing test_delete_calendar_event; hardening needs a factory-created deletable event. Filed as [FEATURE] harden test_delete_calendar_event with factory-created deletable event #1413.

A1: behavior under degraded HA states (down, restarting, partial integration failures) belongs in chaos-engineering scope, not input-archetype scope. Defensibly out.

Closing as resolved. 8 of 9 archetypes closed or substantively covered; 1 defensibly skipped (A1). The two A7 follow-ups now have focused homes in #1412 and #1413.