nsaspy/zara-plugins

Fork 0

[WORKER] Providers+Home — SmartThings, calendar/comms and production integration hardening #55

New issue

Open

opened 2026-09-08 02:02:53 +00:00 by nsaspy · 19 comments

nsaspy commented

2026-09-08 02:02:53 +00:00

Owner

Mission

Continuously expand Zara's real-world provider integrations while preserving typed capability, principal ownership and post-mutation verification. This worker owns account/device/service providers, not generic Core/runtime architecture.

Stagger slot

fleet_cycle = 2h
slot = +75m

Start 15 minutes after Symbolics+Dev (+60m). Preserve the relative stagger if cadence changes.

Primary queue

zara-home production adapters and SmartThings integration with Zara Core #202 seams;
Home Assistant transport/auth/event hardening;
calendar provider implementation and mutation verification;
contacts/comms provider implementations when dependency-satisfied;
provider discovery, OAuth/token lifecycle, reconnect, rate limits and webhook/event correctness;
feature expansion only after existing provider correctness/security gaps are regression-covered.

Feature-expansion rule

Prefer integrations that make Zara materially more useful in daily life: smart-home control, calendar, communications, contacts and other maintained provider APIs. Reuse official APIs and existing typed capability contracts rather than inventing scraping or arbitrary execution shortcuts.

Deep-testing contract

Every provider slice must cover more than the happy HTTP response:

deterministic fake/local provider server tests;
auth/token refresh/revocation and malformed credentials;
pagination/rate-limit/backoff where relevant;
timeout/cancellation and disconnect/reconnect;
stale resource/version and provider-side races;
idempotency/replay for mutations;
two-principal isolation;
secret/log redaction;
provider acknowledgement vs independently observed post-mutation state;
property/fuzz tests for webhook/protocol/schema parsing where useful;
full plugin registry/test/Nix gate at exact head.

A provider returning 2xx/accepted is not proof that the requested state exists. When the provider exposes a read-back path, verify the resulting state before reporting success.

Smart-home invariants

SmartThings OAuth/refresh credentials remain server-side;
Android may host linking UX but does not become credential authority;
device aliases are principal-scoped;
commands are typed and bounded;
event/webhook signatures and replay protections are tested;
one principal cannot enumerate/control another principal's devices;
provider outages degrade explicitly rather than falling back to arbitrary local shell/Intent behavior.

State loop

worker = providers-home
mode = RESEARCH | IMPLEMENT | REVIEW

RESEARCH: current official docs + current repository contracts + #645 findings; freeze one slice.
IMPLEMENT: worktree, tests first, bounded implementation, focused/full gates, PR.
REVIEW: adversarial provider/security/postcondition pass; independent cross-repo final review remains Zara #646.

Output contract

WORKER_STATE
worker: providers-home
mode_used: <RESEARCH|IMPLEMENT|REVIEW>
result: <one-line outcome>
issue_or_pr: <refs or none>
head: <sha or none>
provider_tests: <auth/failure/replay/postcondition summary>
security: <principal/secrets summary>
core_handoffs: <refs or none>
blockers: <summary or none>
next_mode: <RESEARCH|IMPLEMENT|REVIEW>
next_target: <specific provider/slice>

Guardrails

Never commit directly to main.
No secret values in issues, fixtures, logs or PR descriptions.
No arbitrary shell/eval/browser automation as a provider shortcut.
Do not duplicate Core abstractions; file focused handoff blockers.
Prefer correctness/security repair over adding another provider surface.

## Mission Continuously expand Zara's real-world provider integrations while preserving typed capability, principal ownership and post-mutation verification. This worker owns account/device/service providers, not generic Core/runtime architecture. ## Stagger slot ```text fleet_cycle = 2h slot = +75m ``` Start 15 minutes after Symbolics+Dev (+60m). Preserve the relative stagger if cadence changes. ## Primary queue 1. `zara-home` production adapters and SmartThings integration with Zara Core #202 seams; 2. Home Assistant transport/auth/event hardening; 3. calendar provider implementation and mutation verification; 4. contacts/comms provider implementations when dependency-satisfied; 5. provider discovery, OAuth/token lifecycle, reconnect, rate limits and webhook/event correctness; 6. feature expansion only after existing provider correctness/security gaps are regression-covered. ## Feature-expansion rule Prefer integrations that make Zara materially more useful in daily life: smart-home control, calendar, communications, contacts and other maintained provider APIs. Reuse official APIs and existing typed capability contracts rather than inventing scraping or arbitrary execution shortcuts. ## Deep-testing contract Every provider slice must cover more than the happy HTTP response: - deterministic fake/local provider server tests; - auth/token refresh/revocation and malformed credentials; - pagination/rate-limit/backoff where relevant; - timeout/cancellation and disconnect/reconnect; - stale resource/version and provider-side races; - idempotency/replay for mutations; - two-principal isolation; - secret/log redaction; - provider acknowledgement vs independently observed post-mutation state; - property/fuzz tests for webhook/protocol/schema parsing where useful; - full plugin registry/test/Nix gate at exact head. A provider returning 2xx/accepted is not proof that the requested state exists. When the provider exposes a read-back path, verify the resulting state before reporting success. ## Smart-home invariants - SmartThings OAuth/refresh credentials remain server-side; - Android may host linking UX but does not become credential authority; - device aliases are principal-scoped; - commands are typed and bounded; - event/webhook signatures and replay protections are tested; - one principal cannot enumerate/control another principal's devices; - provider outages degrade explicitly rather than falling back to arbitrary local shell/Intent behavior. ## State loop ```text worker = providers-home mode = RESEARCH | IMPLEMENT | REVIEW ``` - RESEARCH: current official docs + current repository contracts + #645 findings; freeze one slice. - IMPLEMENT: worktree, tests first, bounded implementation, focused/full gates, PR. - REVIEW: adversarial provider/security/postcondition pass; independent cross-repo final review remains Zara #646. ## Output contract ```text WORKER_STATE worker: providers-home mode_used: <RESEARCH|IMPLEMENT|REVIEW> result: <one-line outcome> issue_or_pr: <refs or none> head: <sha or none> provider_tests: <auth/failure/replay/postcondition summary> security: <principal/secrets summary> core_handoffs: <refs or none> blockers: <summary or none> next_mode: <RESEARCH|IMPLEMENT|REVIEW> next_target: <specific provider/slice> ``` ## Guardrails - Never commit directly to `main`. - No secret values in issues, fixtures, logs or PR descriptions. - No arbitrary shell/eval/browser automation as a provider shortcut. - Do not duplicate Core abstractions; file focused handoff blockers. - Prefer correctness/security repair over adding another provider surface.

nsaspy commented

2026-09-08 02:17:36 +00:00

Author

Owner

Research evidence: current zara-home source delegates URL/auth/timeouts to an injected transport and has no production transport; Home Assistant's current REST API requires bearer auth, its auth API defines access/refresh-token lifecycle and 401 refresh behavior, and its WebSocket API distinguishes service-call completion from state_changed observation. SmartThings official docs likewise confirm asynchronous command state changes and server-side OAuth/subscription/webhook architecture, reinforcing that Core #202 should remain the SmartThings credential/event authority.

WORKER_STATE worker: providers-home mode_used: RESEARCH result: Froze a dependency-satisfied production Home Assistant transport/auth slice; current zara-home adapter is fixture-only at the transport boundary, while SmartThings server ownership remains correctly in open Core #202. issue_or_pr: #512; Core lost-rob0t/zara#202 head: 683bdd0e66d2d8bc403ca3a4f6ff3bc0c4de3908 tests: not run (research-only slice); #512 requires RED-first local HTTP auth/refresh/failure/postcondition tests, zara-home suite, registry/compatibility gates, and nix flake check at exact head blockers: SmartThings plugin-side integration remains blocked on/owned by Core #202's server-side OAuth/device/event provider seam; do not duplicate credential authority in zara-plugins next_mode: IMPLEMENT next_target: #512 — production Home Assistant HTTP transport with bearer auth, one bounded refresh+retry, secret redaction, URL/path confinement, explicit failure semantics, and preserved post-write read-back verification Research evidence: current zara-home source delegates URL/auth/timeouts to an injected transport and has no production transport; Home Assistant's current REST API requires bearer auth, its auth API defines access/refresh-token lifecycle and 401 refresh behavior, and its WebSocket API distinguishes service-call completion from state_changed observation. SmartThings official docs likewise confirm asynchronous command state changes and server-side OAuth/subscription/webhook architecture, reinforcing that Core #202 should remain the SmartThings credential/event authority.

nsaspy commented

2026-09-08 02:17:37 +00:00

Author

Owner

WORKER_STATE
worker: providers-home
mode_used: IMPLEMENT
result: Implemented #512 as PR #514: production Home Assistant HTTP transport with bearer auth, base/path/method confinement, bounded timeout/response size, structured provider failures, one-shot 401 refresh+retry, explicit reauth-required failure, and environment-backed zara-home configuration while preserving HomeService read-back as the only verification authority.
issue_or_pr: #512; PR #514
head: 2045fc0093
tests: Added RED-first deterministic local HTTP server coverage in test_home_assistant_transport.py for bearer injection without secret evidence, 401 refresh+retry, refresh rejection with no second retry, malformed JSON, 429, path/base confinement; existing HomeService tests already cover provider acknowledgement with mismatched read-back => verified=false and matching observed state => verified=true. Exact-head CI run 34104008756 is pending at this head, so no green claim is made yet.
blockers: No implementation dependency blocker. SmartThings remains blocked on/owned by Core lost-rob0t/zara#202; no SmartThings credential authority was added here. Merge is blocked until exact-head registry/plugin/package/Nix/compatibility gates complete successfully.
next_mode: REVIEW
next_target: Adversarially review PR #514 at exact head for secret leakage, URL/path/method escape, one-shot refresh semantics, stale/provider acknowledgement vs observed state, malformed/429/5xx/timeout coverage, environment/install compatibility, and exact-head gate results; fix any concrete finding before merge.

WORKER_STATE worker: providers-home mode_used: IMPLEMENT result: Implemented #512 as PR #514: production Home Assistant HTTP transport with bearer auth, base/path/method confinement, bounded timeout/response size, structured provider failures, one-shot 401 refresh+retry, explicit reauth-required failure, and environment-backed zara-home configuration while preserving HomeService read-back as the only verification authority. issue_or_pr: #512; PR #514 head: 2045fc0093fe21db4e620f55b282e0d20adec413 tests: Added RED-first deterministic local HTTP server coverage in `test_home_assistant_transport.py` for bearer injection without secret evidence, 401 refresh+retry, refresh rejection with no second retry, malformed JSON, 429, path/base confinement; existing HomeService tests already cover provider acknowledgement with mismatched read-back => verified=false and matching observed state => verified=true. Exact-head CI run 34104008756 is pending at this head, so no green claim is made yet. blockers: No implementation dependency blocker. SmartThings remains blocked on/owned by Core lost-rob0t/zara#202; no SmartThings credential authority was added here. Merge is blocked until exact-head registry/plugin/package/Nix/compatibility gates complete successfully. next_mode: REVIEW next_target: Adversarially review PR #514 at exact head for secret leakage, URL/path/method escape, one-shot refresh semantics, stale/provider acknowledgement vs observed state, malformed/429/5xx/timeout coverage, environment/install compatibility, and exact-head gate results; fix any concrete finding before merge.

nsaspy commented

2026-09-08 02:17:37 +00:00

Author

Owner

WORKER_STATE
worker: providers-home
mode_used: REVIEW
result: Adversarial review of PR #514 found a concrete credential-leak path: malformed initial or refreshed bearer tokens containing HTTP control characters can reach Python header validation, whose uncaught ValueError can include the raw Authorization value; merge should stay blocked until tokens are rejected/sanitized before request construction. Review also confirmed the required timeout/disconnect and 5xx cases are not explicitly regression-covered yet.
issue_or_pr: #512; PR #514; review 5130635442
head: 2045fc0093
provider_tests: Exact-head CI run 34104008756 completed green; existing tests prove bearer injection, one-shot 401 refresh, refresh rejection, malformed JSON, 429, base/path confinement, and HomeService read-back verification semantics. Missing explicit deterministic timeout/disconnect and 5xx coverage remains a contract gap.
security: Concrete secret-leak finding on malformed access/refresh token control characters; URL/method/path confinement, one-shot retry, generic security-sensitive capability blocking, and provider-ack-vs-read-back verification otherwise reviewed sound in this slice. No SmartThings credential authority was added.
core_handoffs: lost-rob0t/zara#202 remains the SmartThings server-side OAuth/device/event authority.
blockers: PR #514 must not merge until malformed-token handling is secret-safe and regression-covered; add the missing timeout/disconnect and 5xx tests at the same focused transport boundary. GitHub cannot submit REQUEST_CHANGES on the author's own PR, so the blocker is recorded as a review comment instead.
next_mode: IMPLEMENT
next_target: PR #514 / #512 — tests-first reject control-character/unsafe bearer tokens for both initial and refreshed credentials without secret-bearing exceptions, then add deterministic timeout/disconnect + 5xx transport tests and rerun exact-head plugin/registry/package/Nix/compatibility gates.

WORKER_STATE worker: providers-home mode_used: REVIEW result: Adversarial review of PR #514 found a concrete credential-leak path: malformed initial or refreshed bearer tokens containing HTTP control characters can reach Python header validation, whose uncaught `ValueError` can include the raw `Authorization` value; merge should stay blocked until tokens are rejected/sanitized before request construction. Review also confirmed the required timeout/disconnect and 5xx cases are not explicitly regression-covered yet. issue_or_pr: #512; PR #514; review 5130635442 head: 2045fc0093fe21db4e620f55b282e0d20adec413 provider_tests: Exact-head CI run 34104008756 completed green; existing tests prove bearer injection, one-shot 401 refresh, refresh rejection, malformed JSON, 429, base/path confinement, and HomeService read-back verification semantics. Missing explicit deterministic timeout/disconnect and 5xx coverage remains a contract gap. security: Concrete secret-leak finding on malformed access/refresh token control characters; URL/method/path confinement, one-shot retry, generic security-sensitive capability blocking, and provider-ack-vs-read-back verification otherwise reviewed sound in this slice. No SmartThings credential authority was added. core_handoffs: lost-rob0t/zara#202 remains the SmartThings server-side OAuth/device/event authority. blockers: PR #514 must not merge until malformed-token handling is secret-safe and regression-covered; add the missing timeout/disconnect and 5xx tests at the same focused transport boundary. GitHub cannot submit REQUEST_CHANGES on the author's own PR, so the blocker is recorded as a review comment instead. next_mode: IMPLEMENT next_target: PR #514 / #512 — tests-first reject control-character/unsafe bearer tokens for both initial and refreshed credentials without secret-bearing exceptions, then add deterministic timeout/disconnect + 5xx transport tests and rerun exact-head plugin/registry/package/Nix/compatibility gates.

nsaspy commented

2026-09-08 02:17:37 +00:00

Author

Owner

WORKER_STATE
worker: providers-home
mode_used: IMPLEMENT
result: Fixed the PR #514 credential-leak blocker tests-first and closed the missing provider-failure coverage: unsafe initial/refreshed bearer credentials are rejected before HTTP header construction with secret-safe structured errors, deterministic timeout/disconnect map to provider-unavailable, and 5xx maps to provider-error.
issue_or_pr: #512; PR #514
head: 3aa24870b1
tests: RED-first test commit 6d51e19b5a added malformed initial/refreshed token, timeout, disconnect, and 503 cases; implementation commit 3aa24870b1 added RFC6750-style bearer-token validation and secret-safe connection failure handling. Exact-head CI run 34114901622 is green: compatibility contract tests, source/installed compatibility diagnostics, registry+plugin tests, package builds, and avatar CPU gate all completed successfully.
provider_tests: Home Assistant transport now explicitly covers bearer injection, one-shot 401 refresh, refresh rejection, unsafe credential rejection before request construction, malformed JSON, 429, 5xx, timeout, disconnect, base/path confinement, plus existing HomeService provider-ack-vs-read-back verification behavior.
security: No bearer values are interpolated into structured failures; unsafe/control/non-bearer credential strings are rejected before Request/urlopen; SmartThings credential authority remains out of this plugin and owned by lost-rob0t/zara#202.
core_handoffs: lost-rob0t/zara#202 remains the SmartThings server-side OAuth/device/event authority.
blockers: none from this implementation slice; PR #514 remains open pending adversarial exact-head review rather than being merged directly from IMPLEMENT.
next_mode: REVIEW
next_target: PR #514 at exact head 3aa24870b1 — re-review bearer-token acceptance compatibility, provider acknowledgement vs independently observed intended state, URL/path/method and capability boundaries, refresh/retry semantics, stale-state behavior, secret redaction, deterministic failure coverage, and whether #512 is complete enough to merge/close.

WORKER_STATE worker: providers-home mode_used: IMPLEMENT result: Fixed the PR #514 credential-leak blocker tests-first and closed the missing provider-failure coverage: unsafe initial/refreshed bearer credentials are rejected before HTTP header construction with secret-safe structured errors, deterministic timeout/disconnect map to provider-unavailable, and 5xx maps to provider-error. issue_or_pr: #512; PR #514 head: 3aa24870b1a822737d65aaeedc52182f2a04da16 tests: RED-first test commit 6d51e19b5a3fcb19e0464041acaa44dc38028026 added malformed initial/refreshed token, timeout, disconnect, and 503 cases; implementation commit 3aa24870b1a822737d65aaeedc52182f2a04da16 added RFC6750-style bearer-token validation and secret-safe connection failure handling. Exact-head CI run 34114901622 is green: compatibility contract tests, source/installed compatibility diagnostics, registry+plugin tests, package builds, and avatar CPU gate all completed successfully. provider_tests: Home Assistant transport now explicitly covers bearer injection, one-shot 401 refresh, refresh rejection, unsafe credential rejection before request construction, malformed JSON, 429, 5xx, timeout, disconnect, base/path confinement, plus existing HomeService provider-ack-vs-read-back verification behavior. security: No bearer values are interpolated into structured failures; unsafe/control/non-bearer credential strings are rejected before Request/urlopen; SmartThings credential authority remains out of this plugin and owned by lost-rob0t/zara#202. core_handoffs: lost-rob0t/zara#202 remains the SmartThings server-side OAuth/device/event authority. blockers: none from this implementation slice; PR #514 remains open pending adversarial exact-head review rather than being merged directly from IMPLEMENT. next_mode: REVIEW next_target: PR #514 at exact head 3aa24870b1a822737d65aaeedc52182f2a04da16 — re-review bearer-token acceptance compatibility, provider acknowledgement vs independently observed intended state, URL/path/method and capability boundaries, refresh/retry semantics, stale-state behavior, secret redaction, deterministic failure coverage, and whether #512 is complete enough to merge/close.

nsaspy commented

2026-09-08 02:17:37 +00:00

Author

Owner

WORKER_STATE
worker: providers-home
mode_used: REVIEW
result: Adversarial exact-head review of PR #514 found a new merge-blocking credential/origin-confinement bug: Python urllib follows redirects by default and carries request headers, so a Home Assistant 30x can forward Authorization: Bearer ... to a different origin despite initial base/path confinement.
issue_or_pr: #512; PR #514; review comment 5570412541
head: 3aa24870b1
tests: Exact-head CI run 34114901622 is green at this head; current deterministic tests cover malformed initial/refreshed bearer rejection, one-shot 401 refresh, refresh failure, malformed JSON, 429, 5xx, timeout, disconnect, and initial base/path confinement. Missing regression: cross-origin redirect must not receive Authorization; same-origin redirect/scheme-downgrade behavior must be explicitly bounded if redirects remain enabled.
provider_tests: Provider acknowledgement remains non-authoritative: HomeService re-reads intended state and stale/mismatched read-back stays verified=false; security-sensitive generic mutations remain blocked. Local fake-provider coverage satisfies #512's CI contract but is not proof of every real Home Assistant reverse-proxy deployment.
security: Malformed-token leak is fixed, but redirect handling can still leak bearer credentials and bypass origin confinement. SmartThings credentials remain server-owned by lost-rob0t/zara#202; no cross-principal/device authority was added in this slice.
core_handoffs: lost-rob0t/zara#202 remains the SmartThings server-side OAuth/device/event authority.
blockers: PR #514 must not merge until redirect behavior is tests-first confined: reject redirects entirely or permit only normalized same-origin redirects without credential leakage; explicitly reject cross-origin redirects and HTTPS-to-HTTP downgrade.
next_mode: IMPLEMENT
next_target: PR #514 / #512 — add RED-first two-server redirect tests proving Authorization never reaches a redirected foreign origin, then implement a bounded redirect policy with structured secret-safe failures and rerun exact-head zara-home/registry/compatibility/package/Nix gates.

WORKER_STATE worker: providers-home mode_used: REVIEW result: Adversarial exact-head review of PR #514 found a new merge-blocking credential/origin-confinement bug: Python urllib follows redirects by default and carries request headers, so a Home Assistant 30x can forward `Authorization: Bearer ...` to a different origin despite initial base/path confinement. issue_or_pr: #512; PR #514; review comment 5570412541 head: 3aa24870b1a822737d65aaeedc52182f2a04da16 tests: Exact-head CI run 34114901622 is green at this head; current deterministic tests cover malformed initial/refreshed bearer rejection, one-shot 401 refresh, refresh failure, malformed JSON, 429, 5xx, timeout, disconnect, and initial base/path confinement. Missing regression: cross-origin redirect must not receive Authorization; same-origin redirect/scheme-downgrade behavior must be explicitly bounded if redirects remain enabled. provider_tests: Provider acknowledgement remains non-authoritative: HomeService re-reads intended state and stale/mismatched read-back stays `verified=false`; security-sensitive generic mutations remain blocked. Local fake-provider coverage satisfies #512's CI contract but is not proof of every real Home Assistant reverse-proxy deployment. security: Malformed-token leak is fixed, but redirect handling can still leak bearer credentials and bypass origin confinement. SmartThings credentials remain server-owned by lost-rob0t/zara#202; no cross-principal/device authority was added in this slice. core_handoffs: lost-rob0t/zara#202 remains the SmartThings server-side OAuth/device/event authority. blockers: PR #514 must not merge until redirect behavior is tests-first confined: reject redirects entirely or permit only normalized same-origin redirects without credential leakage; explicitly reject cross-origin redirects and HTTPS-to-HTTP downgrade. next_mode: IMPLEMENT next_target: PR #514 / #512 — add RED-first two-server redirect tests proving Authorization never reaches a redirected foreign origin, then implement a bounded redirect policy with structured secret-safe failures and rerun exact-head zara-home/registry/compatibility/package/Nix gates.

nsaspy commented

2026-09-08 02:17:37 +00:00

Author

Owner

WORKER_STATE
worker: providers-home
mode_used: IMPLEMENT
result: Closed the PR #514 redirect credential-confinement blocker tests-first: Home Assistant transport now rejects all HTTP redirects before a second request can be issued, so Authorization cannot be forwarded cross-origin and same-origin/downgrade redirects are not implicitly trusted.
issue_or_pr: #512; PR #514
head: e3024d3d72
tests: RED-first commit 5adffd2149 added a two-server cross-origin redirect regression proving the foreign server receives no request/Authorization plus an explicit same-origin redirect rejection test. Implementation commit e3024d3d72 replaced default urlopen redirect following with a rejecting HTTPRedirectHandler and maps every 3xx to secret-safe redirect-not-allowed. A focused reconstructed transport smoke test passed locally (cross-origin redirect, same-origin redirect, normal request). Exact-head CI run 34125901454 completed successfully at e3024d3d72, including compatibility diagnostics/contracts, registry+plugin tests, package builds, and avatar CPU gate.
provider_tests: Redirect coverage now joins bearer injection, malformed initial/refreshed credential rejection, one-shot 401 refresh, refresh rejection, malformed JSON, 429, 5xx, timeout, disconnect, base/path confinement, and existing HomeService provider-ack-vs-read-back verification behavior. No redirect is treated as provider state evidence.
security: Cross-origin credential forwarding is blocked by construction because redirects never produce a follow-up request; same-origin redirects and HTTPS-to-HTTP downgrade redirects are also rejected under the same policy. Structured redirect failures contain no bearer value. SmartThings credential authority remains server-side in lost-rob0t/zara#202.
core_handoffs: lost-rob0t/zara#202 remains the SmartThings server-side OAuth/device/event authority.
blockers: none from this implementation slice; PR #514 remains open pending adversarial exact-head review rather than merge from IMPLEMENT.
next_mode: REVIEW
next_target: PR #514 at exact head e3024d3d72 — adversarially re-check redirect rejection semantics, bearer/token compatibility, provider acknowledgement vs independently observed intended state, URL/path/method/capability boundaries, stale state, refresh/retry behavior, secrets, and real-provider/reverse-proxy coverage; decide merge readiness for #512 from that evidence.

WORKER_STATE worker: providers-home mode_used: IMPLEMENT result: Closed the PR #514 redirect credential-confinement blocker tests-first: Home Assistant transport now rejects all HTTP redirects before a second request can be issued, so Authorization cannot be forwarded cross-origin and same-origin/downgrade redirects are not implicitly trusted. issue_or_pr: #512; PR #514 head: e3024d3d725074b3b35ecd468e1f90cffe2c1b20 tests: RED-first commit 5adffd2149226f2247f6dd2e6a736dae122b93e6 added a two-server cross-origin redirect regression proving the foreign server receives no request/Authorization plus an explicit same-origin redirect rejection test. Implementation commit e3024d3d725074b3b35ecd468e1f90cffe2c1b20 replaced default urlopen redirect following with a rejecting HTTPRedirectHandler and maps every 3xx to secret-safe `redirect-not-allowed`. A focused reconstructed transport smoke test passed locally (cross-origin redirect, same-origin redirect, normal request). Exact-head CI run 34125901454 completed successfully at e3024d3d725074b3b35ecd468e1f90cffe2c1b20, including compatibility diagnostics/contracts, registry+plugin tests, package builds, and avatar CPU gate. provider_tests: Redirect coverage now joins bearer injection, malformed initial/refreshed credential rejection, one-shot 401 refresh, refresh rejection, malformed JSON, 429, 5xx, timeout, disconnect, base/path confinement, and existing HomeService provider-ack-vs-read-back verification behavior. No redirect is treated as provider state evidence. security: Cross-origin credential forwarding is blocked by construction because redirects never produce a follow-up request; same-origin redirects and HTTPS-to-HTTP downgrade redirects are also rejected under the same policy. Structured redirect failures contain no bearer value. SmartThings credential authority remains server-side in lost-rob0t/zara#202. core_handoffs: lost-rob0t/zara#202 remains the SmartThings server-side OAuth/device/event authority. blockers: none from this implementation slice; PR #514 remains open pending adversarial exact-head review rather than merge from IMPLEMENT. next_mode: REVIEW next_target: PR #514 at exact head e3024d3d725074b3b35ecd468e1f90cffe2c1b20 — adversarially re-check redirect rejection semantics, bearer/token compatibility, provider acknowledgement vs independently observed intended state, URL/path/method/capability boundaries, stale state, refresh/retry behavior, secrets, and real-provider/reverse-proxy coverage; decide merge readiness for #512 from that evidence.

nsaspy commented

2026-09-08 02:17:37 +00:00

Author

Owner

WORKER_STATE
worker: providers-home
mode_used: REVIEW
result: Adversarial exact-head re-review cleared the previously found credential/origin blockers; PR #514 now satisfies the bounded #512 Home Assistant HTTP/auth transport contract and is merge-ready from the provider/security/postcondition perspective.
issue_or_pr: #512; PR #514; review comment 5571839371
head: e3024d3d72
tests: Exact-head CI run 34125901454 is green at this SHA. Deterministic coverage now includes bearer injection, malformed initial/refreshed credentials, one-shot 401 refresh and refresh rejection, cross-origin + same-origin redirect rejection, malformed JSON, 429, 5xx, timeout, disconnect, and base/path confinement; existing HomeService tests cover provider acknowledgement followed by matching/mismatched read-back verification.
provider_tests: Provider acknowledgement remains non-authoritative: HomeService.set_property() independently re-reads state and only reports verified=true when observed == requested; stale/mismatched immediate state fails closed. Redirects never become state evidence. Real-provider/reverse-proxy behavior is still intentionally outside deterministic CI proof.
security: Bearer values are validated before request construction and omitted from structured errors; all redirects are rejected before a second request; method/path/base boundaries remain narrow; security-sensitive lock/cover generic mutations remain blocked; numeric capability bounds are enforced before mutation. No SmartThings credential authority was added here.
core_handoffs: lost-rob0t/zara#202 remains the SmartThings server-side OAuth/device/event authority.
blockers: none for #512/PR #514 from this review. PR remains open and was not merged by this worker loop; GitHub reports it mergeable/clean against current main.
next_mode: RESEARCH
next_target: Freeze the next zara-home Home Assistant event-correctness slice from current official WebSocket API semantics: authenticated connection/reconnect, subscription lifecycle, bounded event parsing, stale/out-of-order state_changed handling, and how observed events should complement (not replace) mutation read-back verification. Keep SmartThings OAuth/event ownership in Core #202.

WORKER_STATE worker: providers-home mode_used: REVIEW result: Adversarial exact-head re-review cleared the previously found credential/origin blockers; PR #514 now satisfies the bounded #512 Home Assistant HTTP/auth transport contract and is merge-ready from the provider/security/postcondition perspective. issue_or_pr: #512; PR #514; review comment 5571839371 head: e3024d3d725074b3b35ecd468e1f90cffe2c1b20 tests: Exact-head CI run 34125901454 is green at this SHA. Deterministic coverage now includes bearer injection, malformed initial/refreshed credentials, one-shot 401 refresh and refresh rejection, cross-origin + same-origin redirect rejection, malformed JSON, 429, 5xx, timeout, disconnect, and base/path confinement; existing HomeService tests cover provider acknowledgement followed by matching/mismatched read-back verification. provider_tests: Provider acknowledgement remains non-authoritative: `HomeService.set_property()` independently re-reads state and only reports `verified=true` when observed == requested; stale/mismatched immediate state fails closed. Redirects never become state evidence. Real-provider/reverse-proxy behavior is still intentionally outside deterministic CI proof. security: Bearer values are validated before request construction and omitted from structured errors; all redirects are rejected before a second request; method/path/base boundaries remain narrow; security-sensitive lock/cover generic mutations remain blocked; numeric capability bounds are enforced before mutation. No SmartThings credential authority was added here. core_handoffs: lost-rob0t/zara#202 remains the SmartThings server-side OAuth/device/event authority. blockers: none for #512/PR #514 from this review. PR remains open and was not merged by this worker loop; GitHub reports it mergeable/clean against current main. next_mode: RESEARCH next_target: Freeze the next zara-home Home Assistant event-correctness slice from current official WebSocket API semantics: authenticated connection/reconnect, subscription lifecycle, bounded event parsing, stale/out-of-order `state_changed` handling, and how observed events should complement (not replace) mutation read-back verification. Keep SmartThings OAuth/event ownership in Core #202.

nsaspy commented

2026-09-08 02:17:37 +00:00

Author

Owner

WORKER_STATE
worker: providers-home
mode_used: RESEARCH
result: Froze #519 as the next bounded zara-home correctness slice: a read-only Home Assistant WebSocket state_changed stream with explicit auth/subscription phases, bounded parsing, stale/out-of-order protection, reconnect+reconciliation, and no weakening of independent mutation read-back verification.
issue_or_pr: #519; PR #514; Core lost-rob0t/zara#202
head: main eaef813695; prerequisite transport exact head e3024d3d72
provider_tests: research-only, not run. #519 freezes RED-first deterministic fake-WebSocket coverage for auth ordering/auth_invalid, subscription acknowledgement, malformed/oversized/unrelated frames, supported-domain normalization, older last_updated rejection, disconnect/reconnect with fresh subscription identity, post-reconnect REST reconciliation before freshness, cooperative stop, secret redaction, and matching-event-but-mismatched-independent-readback => verified=false.
security: WebSocket origin is confined to the same configured Home Assistant origin; no redirects/cross-origin credential forwarding; bearer material must stay out of errors/evidence; event cache is observation only and cannot authorize or verify mutations. SmartThings credentials/event authority remain server-side in Core #202.
core_handoffs: lost-rob0t/zara#202 remains the SmartThings OAuth/device/event provider owner; no duplicate SmartThings seam is proposed.
blockers: no research blocker. PR #514 is still open but provider/security review already found it merge-ready and exact-head green; #519 implementation should either start after #514 merges or explicitly stack/rebase on its exact head so the hardened origin/token boundary is reused rather than duplicated.
next_mode: IMPLEMENT
next_target: #519 — tests-first Home Assistant WebSocket auth + state_changed subscription lifecycle, bounded event parser/cache with monotonic last_updated, reconnect/reconcile-before-fresh semantics, and preservation of REST read-back as the only verified=true authority; use a focused branch/worktree and exact-head gates.

Research evidence: current main keeps HomeAssistantAdapter REST-only and HomeService.set_property() independently re-reads provider state before setting verified; Home Assistant's current official WebSocket API requires auth_required -> auth -> auth_ok, correlates command/result/event frames by integer id, requires successful subscribe_events acknowledgement, loses subscriptions on disconnect, and explicitly distinguishes service-call completion from subsequent state observation. Official docs checked: https://developers.home-assistant.io/docs/api/websocket/ , https://developers.home-assistant.io/docs/auth_api/ , https://developers.home-assistant.io/docs/api/rest/ .

WORKER_STATE worker: providers-home mode_used: RESEARCH result: Froze #519 as the next bounded zara-home correctness slice: a read-only Home Assistant WebSocket `state_changed` stream with explicit auth/subscription phases, bounded parsing, stale/out-of-order protection, reconnect+reconciliation, and no weakening of independent mutation read-back verification. issue_or_pr: #519; PR #514; Core lost-rob0t/zara#202 head: main eaef81369584453a5a6020d6043415b2489098ca; prerequisite transport exact head e3024d3d725074b3b35ecd468e1f90cffe2c1b20 provider_tests: research-only, not run. #519 freezes RED-first deterministic fake-WebSocket coverage for auth ordering/auth_invalid, subscription acknowledgement, malformed/oversized/unrelated frames, supported-domain normalization, older `last_updated` rejection, disconnect/reconnect with fresh subscription identity, post-reconnect REST reconciliation before freshness, cooperative stop, secret redaction, and matching-event-but-mismatched-independent-readback => `verified=false`. security: WebSocket origin is confined to the same configured Home Assistant origin; no redirects/cross-origin credential forwarding; bearer material must stay out of errors/evidence; event cache is observation only and cannot authorize or verify mutations. SmartThings credentials/event authority remain server-side in Core #202. core_handoffs: lost-rob0t/zara#202 remains the SmartThings OAuth/device/event provider owner; no duplicate SmartThings seam is proposed. blockers: no research blocker. PR #514 is still open but provider/security review already found it merge-ready and exact-head green; #519 implementation should either start after #514 merges or explicitly stack/rebase on its exact head so the hardened origin/token boundary is reused rather than duplicated. next_mode: IMPLEMENT next_target: #519 — tests-first Home Assistant WebSocket auth + `state_changed` subscription lifecycle, bounded event parser/cache with monotonic `last_updated`, reconnect/reconcile-before-fresh semantics, and preservation of REST read-back as the only `verified=true` authority; use a focused branch/worktree and exact-head gates. Research evidence: current `main` keeps `HomeAssistantAdapter` REST-only and `HomeService.set_property()` independently re-reads provider state before setting `verified`; Home Assistant's current official WebSocket API requires `auth_required` -> auth -> `auth_ok`, correlates command/result/event frames by integer id, requires successful `subscribe_events` acknowledgement, loses subscriptions on disconnect, and explicitly distinguishes service-call completion from subsequent state observation. Official docs checked: https://developers.home-assistant.io/docs/api/websocket/ , https://developers.home-assistant.io/docs/auth_api/ , https://developers.home-assistant.io/docs/api/rest/ .

nsaspy commented

2026-09-08 02:17:37 +00:00

Author

Owner

WORKER_STATE
worker: providers-home
mode_used: IMPLEMENT
result: Implemented one bounded #519 slice as stacked PR #520: tests-first Home Assistant WebSocket auth/subscription protocol core with bounded frames, observation-only state cache, monotonic last_updated, reconnect reconciliation-before-fresh, secret-safe failures, and cooperative stop; mutation verification remains independent REST read-back.
issue_or_pr: #519; PR #520; prerequisite PR #514
head: d7692e2c97
provider_tests: RED-first commit d9a7d92330 introduced the event-stream contract before implementation; implementation commit 0e3cd0ee00 added the stream core; follow-up test correction d7692e2c97 makes acknowledgement sequencing explicit. Coverage includes auth_required -> auth -> auth_ok, auth_invalid secret redaction, subscription result gating, events-before-ack ignored, unrelated IDs/domains ignored, oversized frame fail-closed behavior, stale/out-of-order timestamp rejection, fresh subscription identity on reconnect, REST reconciliation before fresh, and cooperative stop. Exact-head CI run 34141596719 is currently in progress at d7692e2c97; no green claim is made yet.
security: WebSocket URL is derived only from the already-normalized Home Assistant http/https origin to ws/wss /api/websocket; bearer syntax reuses the hardened transport validator and bearer values are never interpolated into structured failures. Event cache is observation-only and cannot authorize or verify mutations. SmartThings credential/event authority remains in lost-rob0t/zara#202.
core_handoffs: lost-rob0t/zara#202 remains the SmartThings OAuth/device/event provider owner.
blockers: PR #520 is intentionally stacked on still-open #514. This bounded slice injects the WebSocket connector rather than adding a concrete maintained client dependency; full #519 production wiring still needs an explicit packaging/Nix-compatible client choice. Exact-head CI must also finish before merge readiness can be claimed.
next_mode: REVIEW
next_target: PR #520 at exact head d7692e2c97 — inspect exact-head gate results and adversarially review auth/subscription ordering, stale/fresh transitions, timestamp comparison, malformed/oversized frames, secret confinement, socket teardown/reconnect behavior, and the injected-connector boundary; from that evidence decide whether to fix the core or freeze/implement the concrete maintained WebSocket client + packaging slice.

WORKER_STATE worker: providers-home mode_used: IMPLEMENT result: Implemented one bounded #519 slice as stacked PR #520: tests-first Home Assistant WebSocket auth/subscription protocol core with bounded frames, observation-only state cache, monotonic `last_updated`, reconnect reconciliation-before-fresh, secret-safe failures, and cooperative stop; mutation verification remains independent REST read-back. issue_or_pr: #519; PR #520; prerequisite PR #514 head: d7692e2c97d92daba0a9b238c23f736c3ef6cc99 provider_tests: RED-first commit d9a7d92330481119c00c42d066282cb58b044761 introduced the event-stream contract before implementation; implementation commit 0e3cd0ee004d7f1f6e1cdc03aad09fd1921e02cb added the stream core; follow-up test correction d7692e2c97d92daba0a9b238c23f736c3ef6cc99 makes acknowledgement sequencing explicit. Coverage includes auth_required -> auth -> auth_ok, auth_invalid secret redaction, subscription result gating, events-before-ack ignored, unrelated IDs/domains ignored, oversized frame fail-closed behavior, stale/out-of-order timestamp rejection, fresh subscription identity on reconnect, REST reconciliation before fresh, and cooperative stop. Exact-head CI run 34141596719 is currently in progress at d7692e2c97d92daba0a9b238c23f736c3ef6cc99; no green claim is made yet. security: WebSocket URL is derived only from the already-normalized Home Assistant http/https origin to ws/wss `/api/websocket`; bearer syntax reuses the hardened transport validator and bearer values are never interpolated into structured failures. Event cache is observation-only and cannot authorize or verify mutations. SmartThings credential/event authority remains in lost-rob0t/zara#202. core_handoffs: lost-rob0t/zara#202 remains the SmartThings OAuth/device/event provider owner. blockers: PR #520 is intentionally stacked on still-open #514. This bounded slice injects the WebSocket connector rather than adding a concrete maintained client dependency; full #519 production wiring still needs an explicit packaging/Nix-compatible client choice. Exact-head CI must also finish before merge readiness can be claimed. next_mode: REVIEW next_target: PR #520 at exact head d7692e2c97d92daba0a9b238c23f736c3ef6cc99 — inspect exact-head gate results and adversarially review auth/subscription ordering, stale/fresh transitions, timestamp comparison, malformed/oversized frames, secret confinement, socket teardown/reconnect behavior, and the injected-connector boundary; from that evidence decide whether to fix the core or freeze/implement the concrete maintained WebSocket client + packaging slice.

nsaspy commented

2026-09-08 02:17:37 +00:00

Author

Owner

WORKER_STATE
worker: providers-home
mode_used: REVIEW
result: Adversarial exact-head review of PR #520 found a merge-blocking stale-cache correctness bug: reconnect reconciliation only upserts current states and can mark the stream fresh while retaining an entity removed during downtime; live state_changed removal with new_state: null is also ignored, leaving stale observation data.
issue_or_pr: #519; PR #520; review comment 5573727447; prerequisite PR #514
head: d7692e2c97
provider_tests: Exact-head CI run 34141596719 is green at this SHA. Existing tests cover auth_required -> auth -> auth_ok, auth_invalid redaction, subscription acknowledgement gating, events-before-ack ignored, unrelated IDs/domains, bounded/invalid frames, stale/out-of-order last_updated, reconnect with fresh subscription identity, reconcile-before-fresh ordering, and cooperative stop. Missing regression now identified: cached entity absent from authoritative reconnect snapshot must be evicted before fresh=true, and live state_changed removal/new_state=null must evict rather than preserve stale state.
security: Bearer validation/origin derivation remain confined and secret-safe; event cache remains observation-only and cannot authorize or verify mutations; HomeService independent REST read-back remains the only verified=true authority. SmartThings credentials/event ownership remains in lost-rob0t/zara#202. No provider-acknowledgement regression found in this review.
core_handoffs: lost-rob0t/zara#202 remains the SmartThings OAuth/device/event provider owner.
blockers: PR #520 must not merge until stale entity removal is tests-first defined and fixed. The injected WebSocket connector remains an intentional later production-wiring/package gap, but this correctness blocker comes first. PR #514 is still open as the stacked transport prerequisite.
next_mode: IMPLEMENT
next_target: PR #520 / #519 — tests first for (1) reconnect reconciliation evicting a previously cached supported entity absent from the authoritative current-state snapshot before fresh=true and (2) live state_changed removal with new_state=null evicting that entity; implement bounded tombstone/removal semantics without weakening monotonic replacement ordering, then rerun exact-head zara-home/registry/compatibility/package/Nix gates.

WORKER_STATE worker: providers-home mode_used: REVIEW result: Adversarial exact-head review of PR #520 found a merge-blocking stale-cache correctness bug: reconnect reconciliation only upserts current states and can mark the stream fresh while retaining an entity removed during downtime; live `state_changed` removal with `new_state: null` is also ignored, leaving stale observation data. issue_or_pr: #519; PR #520; review comment 5573727447; prerequisite PR #514 head: d7692e2c97d92daba0a9b238c23f736c3ef6cc99 provider_tests: Exact-head CI run 34141596719 is green at this SHA. Existing tests cover auth_required -> auth -> auth_ok, auth_invalid redaction, subscription acknowledgement gating, events-before-ack ignored, unrelated IDs/domains, bounded/invalid frames, stale/out-of-order last_updated, reconnect with fresh subscription identity, reconcile-before-fresh ordering, and cooperative stop. Missing regression now identified: cached entity absent from authoritative reconnect snapshot must be evicted before fresh=true, and live state_changed removal/new_state=null must evict rather than preserve stale state. security: Bearer validation/origin derivation remain confined and secret-safe; event cache remains observation-only and cannot authorize or verify mutations; HomeService independent REST read-back remains the only verified=true authority. SmartThings credentials/event ownership remains in lost-rob0t/zara#202. No provider-acknowledgement regression found in this review. core_handoffs: lost-rob0t/zara#202 remains the SmartThings OAuth/device/event provider owner. blockers: PR #520 must not merge until stale entity removal is tests-first defined and fixed. The injected WebSocket connector remains an intentional later production-wiring/package gap, but this correctness blocker comes first. PR #514 is still open as the stacked transport prerequisite. next_mode: IMPLEMENT next_target: PR #520 / #519 — tests first for (1) reconnect reconciliation evicting a previously cached supported entity absent from the authoritative current-state snapshot before fresh=true and (2) live state_changed removal with new_state=null evicting that entity; implement bounded tombstone/removal semantics without weakening monotonic replacement ordering, then rerun exact-head zara-home/registry/compatibility/package/Nix gates.

nsaspy commented

2026-09-08 02:17:37 +00:00

Author

Owner

WORKER_STATE
worker: providers-home
mode_used: IMPLEMENT
result: Fixed the PR #520 stale-entity correctness blocker tests-first: reconnect reconciliation now evicts supported cached entities absent from the authoritative current-state snapshot before fresh=true, and live state_changed removals with new_state: null now evict via monotonic tombstones instead of preserving stale observation state.
issue_or_pr: #519; PR #520; prerequisite PR #514
head: 3ef051c3f3
tests: RED-first commit 3976f119ca adds regressions for authoritative reconnect eviction and live removal/tombstone ordering. Implementation commit 3ef051c3f3 adds authoritative membership eviction during reconciliation plus time_fired-ordered removal handling that preserves a timestamp fence against stale resurrection. Exact-head CI run 34149835008 is currently in progress at this SHA; no green claim is made yet.
provider_tests: Existing #520 coverage still includes auth ordering, secret-safe auth failure, subscription acknowledgement gating, bounded/malformed frames, unrelated IDs/domains, monotonic state replacement, reconnect with fresh subscription identity, reconcile-before-fresh, and cooperative stop. New coverage specifically proves an entity removed during downtime is absent once the reconciled stream becomes fresh, and that an older removal cannot erase a newer state while a newer removal does evict it.
security: No credential or principal boundary changed. WebSocket remains same-origin and event-derived state remains observation-only; HomeService independent REST read-back remains the only verified=true authority. SmartThings OAuth/device/event ownership remains in lost-rob0t/zara#202.
core_handoffs: lost-rob0t/zara#202 remains the SmartThings server-side OAuth/device/event provider owner.
blockers: Exact-head CI 34149835008 must complete successfully before merge readiness can be claimed. PR #520 remains intentionally stacked on still-open #514, and the concrete maintained WebSocket client/package wiring remains a later #519 production slice.
next_mode: REVIEW
next_target: PR #520 at exact head 3ef051c3f3 — inspect exact-head gate results and adversarially review authoritative reconciliation semantics, tombstone timestamp ordering/stale resurrection, malformed removal events, cache freshness transitions, secret confinement, and preservation of independent REST mutation verification; then decide whether this core slice is merge-ready before moving to concrete WebSocket client/Nix packaging.

WORKER_STATE worker: providers-home mode_used: IMPLEMENT result: Fixed the PR #520 stale-entity correctness blocker tests-first: reconnect reconciliation now evicts supported cached entities absent from the authoritative current-state snapshot before `fresh=true`, and live `state_changed` removals with `new_state: null` now evict via monotonic tombstones instead of preserving stale observation state. issue_or_pr: #519; PR #520; prerequisite PR #514 head: 3ef051c3f379382aca8cba98628687c9f7fd5a18 tests: RED-first commit 3976f119caa341efc2155bf9970a1d626223eef6 adds regressions for authoritative reconnect eviction and live removal/tombstone ordering. Implementation commit 3ef051c3f379382aca8cba98628687c9f7fd5a18 adds authoritative membership eviction during reconciliation plus `time_fired`-ordered removal handling that preserves a timestamp fence against stale resurrection. Exact-head CI run 34149835008 is currently in progress at this SHA; no green claim is made yet. provider_tests: Existing #520 coverage still includes auth ordering, secret-safe auth failure, subscription acknowledgement gating, bounded/malformed frames, unrelated IDs/domains, monotonic state replacement, reconnect with fresh subscription identity, reconcile-before-fresh, and cooperative stop. New coverage specifically proves an entity removed during downtime is absent once the reconciled stream becomes fresh, and that an older removal cannot erase a newer state while a newer removal does evict it. security: No credential or principal boundary changed. WebSocket remains same-origin and event-derived state remains observation-only; HomeService independent REST read-back remains the only `verified=true` authority. SmartThings OAuth/device/event ownership remains in lost-rob0t/zara#202. core_handoffs: lost-rob0t/zara#202 remains the SmartThings server-side OAuth/device/event provider owner. blockers: Exact-head CI 34149835008 must complete successfully before merge readiness can be claimed. PR #520 remains intentionally stacked on still-open #514, and the concrete maintained WebSocket client/package wiring remains a later #519 production slice. next_mode: REVIEW next_target: PR #520 at exact head 3ef051c3f379382aca8cba98628687c9f7fd5a18 — inspect exact-head gate results and adversarially review authoritative reconciliation semantics, tombstone timestamp ordering/stale resurrection, malformed removal events, cache freshness transitions, secret confinement, and preservation of independent REST mutation verification; then decide whether this core slice is merge-ready before moving to concrete WebSocket client/Nix packaging.

nsaspy commented

2026-09-08 02:17:37 +00:00

Author

Owner

WORKER_STATE
worker: providers-home
mode_used: REVIEW
result: Adversarial exact-head review cleared the stale-removal fix but found a remaining #519 merge blocker: the Home Assistant event stream has no bounded reconnect/backoff driver, no enforced recv/auth timeout, and no production plugin wiring, so a stalled provider can block indefinitely and disconnect recovery is still manual.
issue_or_pr: #519; PR #520; review comment 5574702029
head: 3ef051c3f3
tests: Exact-head CI run 34149835008 completed green at this SHA. Current tests cover auth ordering, subscription acknowledgement, malformed/oversized frames, unsupported domains/unrelated IDs, monotonic last_updated, reconnect reconciliation, absent-entity eviction, live removal tombstones, fresh subscription IDs, and cooperative socket close. Missing required lifecycle proof: stalled recv/auth timeout, automatic bounded reconnect/backoff, stop cancelling reconnect wait/loop, and production stream startup/wiring.
provider_tests: Provider acknowledgement/event observation remains non-authoritative: event-derived state is observation-only and HomeService's independent REST read-back remains the mutation verification authority. Stale entity eviction and removal ordering now look sound for the covered manual session lifecycle.
security: Access-token validation/error confinement, same-origin websocket derivation, supported-domain filtering, and timestamp fences look sound in this slice. No SmartThings credential authority was added; Core lost-rob0t/zara#202 remains owner of SmartThings OAuth/device/event authority.
core_handoffs: lost-rob0t/zara#202 remains the SmartThings server-side OAuth/device/event authority.
blockers: PR #520 should not merge as completing #519 until the event stream has bounded timeout + reconnect/backoff lifecycle semantics and a production-start path; current sock.recv() may block indefinitely and reconnect is caller-manual. Concrete production WebSocket dependency/package wiring may be split only if kept as an explicit blocker/follow-up.
next_mode: IMPLEMENT
next_target: PR #520 / #519 — tests first add a deterministic bounded reconnect/session driver with injected clock/sleeper, enforce handshake/read timeout semantics at the connector boundary, prove stop cancels reconnect waits, and wire startup through zara-home configuration while preserving REST read-back as the only mutation verification authority.

WORKER_STATE worker: providers-home mode_used: REVIEW result: Adversarial exact-head review cleared the stale-removal fix but found a remaining #519 merge blocker: the Home Assistant event stream has no bounded reconnect/backoff driver, no enforced recv/auth timeout, and no production plugin wiring, so a stalled provider can block indefinitely and disconnect recovery is still manual. issue_or_pr: #519; PR #520; review comment 5574702029 head: 3ef051c3f379382aca8cba98628687c9f7fd5a18 tests: Exact-head CI run 34149835008 completed green at this SHA. Current tests cover auth ordering, subscription acknowledgement, malformed/oversized frames, unsupported domains/unrelated IDs, monotonic last_updated, reconnect reconciliation, absent-entity eviction, live removal tombstones, fresh subscription IDs, and cooperative socket close. Missing required lifecycle proof: stalled recv/auth timeout, automatic bounded reconnect/backoff, stop cancelling reconnect wait/loop, and production stream startup/wiring. provider_tests: Provider acknowledgement/event observation remains non-authoritative: event-derived state is observation-only and HomeService's independent REST read-back remains the mutation verification authority. Stale entity eviction and removal ordering now look sound for the covered manual session lifecycle. security: Access-token validation/error confinement, same-origin websocket derivation, supported-domain filtering, and timestamp fences look sound in this slice. No SmartThings credential authority was added; Core lost-rob0t/zara#202 remains owner of SmartThings OAuth/device/event authority. core_handoffs: lost-rob0t/zara#202 remains the SmartThings server-side OAuth/device/event authority. blockers: PR #520 should not merge as completing #519 until the event stream has bounded timeout + reconnect/backoff lifecycle semantics and a production-start path; current `sock.recv()` may block indefinitely and reconnect is caller-manual. Concrete production WebSocket dependency/package wiring may be split only if kept as an explicit blocker/follow-up. next_mode: IMPLEMENT next_target: PR #520 / #519 — tests first add a deterministic bounded reconnect/session driver with injected clock/sleeper, enforce handshake/read timeout semantics at the connector boundary, prove stop cancels reconnect waits, and wire startup through zara-home configuration while preserving REST read-back as the only mutation verification authority.

nsaspy commented

2026-09-08 02:17:37 +00:00

Author

Owner

WORKER_STATE
worker: providers-home
mode_used: IMPLEMENT
result: Implemented one bounded #519 lifecycle slice on PR #520 tests-first: the Home Assistant event stream now has bounded socket read timeout configuration, automatic reconnect with bounded backoff, and cancellation-aware reconnect waits; concrete WebSocket package/Nix + plugin startup wiring remains explicit follow-up work rather than being faked.
issue_or_pr: #519; PR #520; prerequisite PR #514
head: 9d7353c661
tests: RED-first commit 213511b119 adds deterministic lifecycle tests for socket timeout before auth receive, two-session automatic reconnect with bounded backoff, stop cancelling reconnect wait before another connect, and invalid timeout/backoff bounds. Implementation commit 9d7353c661 adds io_timeout_seconds, bounded reconnect policy, stop-event cancellation, run_forever(), and a from_transport() production construction seam. Exact-head CI run 34158057712 is pending at this SHA; no green claim is made.
provider_tests: Existing auth/subscription, bounded frame, stale/out-of-order, authoritative reconciliation, tombstone removal, fresh-subscription identity, and cooperative-close coverage remains in place. This slice adds lifecycle recovery/timeout coverage. Provider events remain observation-only; HomeService independent REST read-back remains the only verified=true authority.
security: Same-origin WebSocket derivation and bearer validation/error confinement are unchanged. Reconnect delays and I/O timeout are bounded (<=60s); stop is cancellation-aware. No SmartThings credential authority was added; lost-rob0t/zara#202 remains the SmartThings OAuth/device/event owner.
core_handoffs: lost-rob0t/zara#202 remains the SmartThings server-side OAuth/device/event authority.
blockers: PR #520 still lacks the concrete maintained WebSocket dependency in plugins.json/Nix packaging and plugin-owned production startup/stop wiring. from_transport() deliberately fails secret-safe if the client module is unavailable. PR #520 also remains stacked on still-open #514. Exact-head CI 34158057712 must finish before merge readiness can be claimed.
next_mode: REVIEW
next_target: PR #520 at exact head 9d7353c661 — adversarially inspect exact-head CI and the new reconnect loop for timeout enforcement, busy-loop/backoff behavior, cancellation races, socket teardown, auth/subscription freshness reset, and secrets; also verify whether concrete websocket-client registry/Nix dependency + ZaraHomePlugin start/stop wiring can be safely completed as the next bounded implementation slice.

WORKER_STATE worker: providers-home mode_used: IMPLEMENT result: Implemented one bounded #519 lifecycle slice on PR #520 tests-first: the Home Assistant event stream now has bounded socket read timeout configuration, automatic reconnect with bounded backoff, and cancellation-aware reconnect waits; concrete WebSocket package/Nix + plugin startup wiring remains explicit follow-up work rather than being faked. issue_or_pr: #519; PR #520; prerequisite PR #514 head: 9d7353c66191b35aa3354b11aa01ca2a232def05 tests: RED-first commit 213511b1196262b4c7822e4feccaa3a8d4ee8df9 adds deterministic lifecycle tests for socket timeout before auth receive, two-session automatic reconnect with bounded backoff, stop cancelling reconnect wait before another connect, and invalid timeout/backoff bounds. Implementation commit 9d7353c66191b35aa3354b11aa01ca2a232def05 adds `io_timeout_seconds`, bounded reconnect policy, stop-event cancellation, `run_forever()`, and a `from_transport()` production construction seam. Exact-head CI run 34158057712 is pending at this SHA; no green claim is made. provider_tests: Existing auth/subscription, bounded frame, stale/out-of-order, authoritative reconciliation, tombstone removal, fresh-subscription identity, and cooperative-close coverage remains in place. This slice adds lifecycle recovery/timeout coverage. Provider events remain observation-only; HomeService independent REST read-back remains the only `verified=true` authority. security: Same-origin WebSocket derivation and bearer validation/error confinement are unchanged. Reconnect delays and I/O timeout are bounded (<=60s); stop is cancellation-aware. No SmartThings credential authority was added; lost-rob0t/zara#202 remains the SmartThings OAuth/device/event owner. core_handoffs: lost-rob0t/zara#202 remains the SmartThings server-side OAuth/device/event authority. blockers: PR #520 still lacks the concrete maintained WebSocket dependency in `plugins.json`/Nix packaging and plugin-owned production startup/stop wiring. `from_transport()` deliberately fails secret-safe if the client module is unavailable. PR #520 also remains stacked on still-open #514. Exact-head CI 34158057712 must finish before merge readiness can be claimed. next_mode: REVIEW next_target: PR #520 at exact head 9d7353c66191b35aa3354b11aa01ca2a232def05 — adversarially inspect exact-head CI and the new reconnect loop for timeout enforcement, busy-loop/backoff behavior, cancellation races, socket teardown, auth/subscription freshness reset, and secrets; also verify whether concrete `websocket-client` registry/Nix dependency + ZaraHomePlugin start/stop wiring can be safely completed as the next bounded implementation slice.

nsaspy commented

2026-09-08 02:17:37 +00:00

Author

Owner

WORKER_STATE
worker: providers-home
mode_used: REVIEW
result: Exact-head lifecycle review is green and the reconnect/timeout core is sound enough to advance, but #519 is still incomplete because zara-home does not construct/start/stop the event stream and the packaged plugin lacks the concrete websocket-client dependency/import proof.
issue_or_pr: #519; PR #520; review comment 5575614735
head: 9d7353c661
provider_tests: Exact-head CI run 34158057712 completed green. Current tests cover bounded socket timeout before auth reads, bounded reconnect backoff, reconnect with fresh auth/subscription identity, cancellation during reconnect wait, auth/subscription gating, malformed/oversized frames, authoritative reconciliation, tombstone/removal ordering, stale/out-of-order state rejection, secret-safe auth failure, and preservation of REST read-back as the only mutation verification authority. Review found the real packaged connector/startup path is still untested because ZaraHomePlugin lifecycle is a no-op and registry dependencies omit websocket-client.
security: Same-origin ws/wss derivation, validated bearer reuse, secret-safe errors, supported-domain filtering, bounded I/O/backoff, and observation-only event semantics remain sound in this slice. No provider acknowledgement or event is promoted to verified=true; HomeService independent REST read-back remains authoritative. SmartThings credentials/event authority remain server-side in lost-rob0t/zara#202.
core_handoffs: lost-rob0t/zara#202 remains the SmartThings OAuth/device/event provider owner.
blockers: PR #520 should not merge as completing #519 until production lifecycle/package wiring exists: share the hardened HomeAssistantHTTPTransport, construct HomeAssistantEventStream.from_transport(), start it from ZaraHomePlugin.start(), stop/join it boundedly from plugin stop, add narrowly scoped websocket-client registry/Nix packaging, and prove a real package import/startup smoke path. PR #520 also remains stacked on still-open #514.
next_mode: IMPLEMENT
next_target: PR #520 / #519 — tests first for plugin-owned HA event-stream startup/stop, missing-client degradation and packaged websocket import; add websocket-client to the zara-home registry/Nix dependency path; wire the configured hardened transport into both HomeAssistantAdapter and HomeAssistantEventStream; start one read-only stream in ZaraHomePlugin lifecycle and stop/join it cooperatively; preserve independent REST verification. Reset reconnect backoff after a successfully fresh session as bounded lifecycle hardening if it fits this slice.

WORKER_STATE worker: providers-home mode_used: REVIEW result: Exact-head lifecycle review is green and the reconnect/timeout core is sound enough to advance, but #519 is still incomplete because zara-home does not construct/start/stop the event stream and the packaged plugin lacks the concrete `websocket-client` dependency/import proof. issue_or_pr: #519; PR #520; review comment 5575614735 head: 9d7353c66191b35aa3354b11aa01ca2a232def05 provider_tests: Exact-head CI run 34158057712 completed green. Current tests cover bounded socket timeout before auth reads, bounded reconnect backoff, reconnect with fresh auth/subscription identity, cancellation during reconnect wait, auth/subscription gating, malformed/oversized frames, authoritative reconciliation, tombstone/removal ordering, stale/out-of-order state rejection, secret-safe auth failure, and preservation of REST read-back as the only mutation verification authority. Review found the real packaged connector/startup path is still untested because ZaraHomePlugin lifecycle is a no-op and registry dependencies omit websocket-client. security: Same-origin ws/wss derivation, validated bearer reuse, secret-safe errors, supported-domain filtering, bounded I/O/backoff, and observation-only event semantics remain sound in this slice. No provider acknowledgement or event is promoted to `verified=true`; HomeService independent REST read-back remains authoritative. SmartThings credentials/event authority remain server-side in lost-rob0t/zara#202. core_handoffs: lost-rob0t/zara#202 remains the SmartThings OAuth/device/event provider owner. blockers: PR #520 should not merge as completing #519 until production lifecycle/package wiring exists: share the hardened HomeAssistantHTTPTransport, construct HomeAssistantEventStream.from_transport(), start it from ZaraHomePlugin.start(), stop/join it boundedly from plugin stop, add narrowly scoped websocket-client registry/Nix packaging, and prove a real package import/startup smoke path. PR #520 also remains stacked on still-open #514. next_mode: IMPLEMENT next_target: PR #520 / #519 — tests first for plugin-owned HA event-stream startup/stop, missing-client degradation and packaged websocket import; add `websocket-client` to the zara-home registry/Nix dependency path; wire the configured hardened transport into both HomeAssistantAdapter and HomeAssistantEventStream; start one read-only stream in ZaraHomePlugin lifecycle and stop/join it cooperatively; preserve independent REST verification. Reset reconnect backoff after a successfully fresh session as bounded lifecycle hardening if it fits this slice.

nsaspy commented

2026-09-08 02:17:37 +00:00

Author

Owner

WORKER_STATE
worker: providers-home
mode_used: IMPLEMENT
result: Landed one bounded tests-first production lifecycle slice on PR #520: ZaraHomePlugin now owns Home Assistant event-stream start/stop, shares the hardened HTTP transport between REST adapter and event observer construction, and performs bounded shutdown without changing REST read-back verification authority.
issue_or_pr: #519; PR #520; prerequisite PR #514
head: 05465dcedb
tests: RED-first commit 7c543d3c9e adds plugin lifecycle coverage for event start/stop/bounded join and REST-only operation without an event stream. Implementation commit 05465dcedb wires shared-transport event construction and plugin lifecycle. Exact-head CI run 34165464628 is queued at this SHA; no green claim is made.
provider_tests: Existing #520 coverage remains for auth/subscription ordering, bounded/malformed frames, reconnect/backoff, authoritative reconciliation, tombstones/removals, stale/out-of-order observations, cancellation, and secret-safe failures. This slice adds production plugin ownership. Provider events remain observation-only; HomeService independent REST read-back remains the only path to verified=true.
security: The event stream is constructed from the same HomeAssistantHTTPTransport origin/token boundary used by the REST adapter; no new credential authority, cross-origin path, arbitrary execution fallback, or secret evidence was added. SmartThings remains server-side in lost-rob0t/zara#202.
core_handoffs: lost-rob0t/zara#202 remains the SmartThings OAuth/device/event provider owner.
blockers: Concrete websocket-client registry/Nix dependency and packaged import/startup smoke proof are still missing, so #519/#520 are not complete. Prerequisite PR #514 is still open and GitHub currently reports it non-mergeable against current main. Exact-head CI 34165464628 must also complete.
next_mode: IMPLEMENT
next_target: PR #520 / #519 — add narrowly scoped websocket-client to zara-home registry/Nix runtime, add packaged runtime import/startup smoke coverage, resolve/rebase the #514 prerequisite if needed, and rerun exact-head registry/plugin/package/Nix/compatibility gates; preserve REST read-back as sole mutation verification authority.

WORKER_STATE worker: providers-home mode_used: IMPLEMENT result: Landed one bounded tests-first production lifecycle slice on PR #520: ZaraHomePlugin now owns Home Assistant event-stream start/stop, shares the hardened HTTP transport between REST adapter and event observer construction, and performs bounded shutdown without changing REST read-back verification authority. issue_or_pr: #519; PR #520; prerequisite PR #514 head: 05465dcedb693608b3b17cef2aa713ed004fbb89 tests: RED-first commit 7c543d3c9e56b6b3954f4d7f5476f605a8fb3efb adds plugin lifecycle coverage for event start/stop/bounded join and REST-only operation without an event stream. Implementation commit 05465dcedb693608b3b17cef2aa713ed004fbb89 wires shared-transport event construction and plugin lifecycle. Exact-head CI run 34165464628 is queued at this SHA; no green claim is made. provider_tests: Existing #520 coverage remains for auth/subscription ordering, bounded/malformed frames, reconnect/backoff, authoritative reconciliation, tombstones/removals, stale/out-of-order observations, cancellation, and secret-safe failures. This slice adds production plugin ownership. Provider events remain observation-only; HomeService independent REST read-back remains the only path to verified=true. security: The event stream is constructed from the same HomeAssistantHTTPTransport origin/token boundary used by the REST adapter; no new credential authority, cross-origin path, arbitrary execution fallback, or secret evidence was added. SmartThings remains server-side in lost-rob0t/zara#202. core_handoffs: lost-rob0t/zara#202 remains the SmartThings OAuth/device/event provider owner. blockers: Concrete websocket-client registry/Nix dependency and packaged import/startup smoke proof are still missing, so #519/#520 are not complete. Prerequisite PR #514 is still open and GitHub currently reports it non-mergeable against current main. Exact-head CI 34165464628 must also complete. next_mode: IMPLEMENT next_target: PR #520 / #519 — add narrowly scoped `websocket-client` to zara-home registry/Nix runtime, add packaged runtime import/startup smoke coverage, resolve/rebase the #514 prerequisite if needed, and rerun exact-head registry/plugin/package/Nix/compatibility gates; preserve REST read-back as sole mutation verification authority.

nsaspy commented

2026-09-08 02:17:37 +00:00

Author

Owner

WORKER_STATE
worker: providers-home
mode_used: IMPLEMENT
result: Completed the bounded zara-home production WebSocket packaging slice on PR #520: tests first require the registry dependency/import path, zara-home now declares websocket-client, and the Nix runtime-layout gate now imports the real websocket client plus HomeAssistantEventStream from the packaged immutable runtime.
issue_or_pr: #519; PR #520; prerequisite PR #514
head: 45efd02d8c
provider_tests: RED-first commit 5e37228137 adds registry + production websocket import requirements. Implementation commits 094eb04916 and 45efd02d8c add the declared websocket-client dependency and packaged Nix runtime smoke. Existing #520 coverage still covers auth/subscription ordering, bounded frames/I/O, reconnect/backoff, authoritative reconciliation, tombstones/removals, stale/out-of-order observations, cancellation, lifecycle start/stop, secret-safe failures, and REST read-back as sole mutation verification authority. Exact-head CI run 34168698910 is pending; no green claim.
security: No new credential authority or cross-origin path was introduced. The concrete connector still derives from the shared hardened HomeAssistantHTTPTransport, event state remains observation-only, and provider acknowledgement/events cannot produce verified=true. SmartThings OAuth/device/event authority remains in lost-rob0t/zara#202.
core_handoffs: lost-rob0t/zara#202 remains SmartThings server-side OAuth/device/event provider owner.
blockers: Exact-head CI 34168698910 must complete. PR #520 is still stacked on open prerequisite #514, although GitHub currently reports both #514 and #520 mergeable.
next_mode: REVIEW
next_target: Adversarially review PR #520 at 45efd02d8c after exact-head CI: verify packaged websocket-client resolution on Nix, runtime import/startup path, missing/broken-client degradation, reconnect/backoff reset behavior, thread shutdown, secret confinement, same-origin boundaries, stale-state semantics, and continued independent REST post-mutation verification; also reassess #514/#520 stack merge readiness.

WORKER_STATE worker: providers-home mode_used: IMPLEMENT result: Completed the bounded zara-home production WebSocket packaging slice on PR #520: tests first require the registry dependency/import path, zara-home now declares `websocket-client`, and the Nix runtime-layout gate now imports the real websocket client plus HomeAssistantEventStream from the packaged immutable runtime. issue_or_pr: #519; PR #520; prerequisite PR #514 head: 45efd02d8c85f3c15578b26140cf671e6f49fec1 provider_tests: RED-first commit 5e372281372bb1f96a782b1d8b142403d407985e adds registry + production websocket import requirements. Implementation commits 094eb04916c05fbe4cf6aee9b3a0ae013cd00c20 and 45efd02d8c85f3c15578b26140cf671e6f49fec1 add the declared websocket-client dependency and packaged Nix runtime smoke. Existing #520 coverage still covers auth/subscription ordering, bounded frames/I/O, reconnect/backoff, authoritative reconciliation, tombstones/removals, stale/out-of-order observations, cancellation, lifecycle start/stop, secret-safe failures, and REST read-back as sole mutation verification authority. Exact-head CI run 34168698910 is pending; no green claim. security: No new credential authority or cross-origin path was introduced. The concrete connector still derives from the shared hardened HomeAssistantHTTPTransport, event state remains observation-only, and provider acknowledgement/events cannot produce verified=true. SmartThings OAuth/device/event authority remains in lost-rob0t/zara#202. core_handoffs: lost-rob0t/zara#202 remains SmartThings server-side OAuth/device/event provider owner. blockers: Exact-head CI 34168698910 must complete. PR #520 is still stacked on open prerequisite #514, although GitHub currently reports both #514 and #520 mergeable. next_mode: REVIEW next_target: Adversarially review PR #520 at 45efd02d8c85f3c15578b26140cf671e6f49fec1 after exact-head CI: verify packaged websocket-client resolution on Nix, runtime import/startup path, missing/broken-client degradation, reconnect/backoff reset behavior, thread shutdown, secret confinement, same-origin boundaries, stale-state semantics, and continued independent REST post-mutation verification; also reassess #514/#520 stack merge readiness.

nsaspy commented

2026-09-08 02:17:37 +00:00

Author

Owner

WORKER_STATE
mode_used: REVIEW
result: BLOCKED — exact-head CI is green and packaged websocket-client runtime coverage is present, but reconnect backoff never resets after a fully established/fresh Home Assistant session; early failures can therefore leave all later reconnects paying the maximum delay even after recovery.
issue_or_pr: #519 / PR #520
head: 45efd02d8c
tests: exact-head GitHub Actions run 34168698910 completed green (test and zara-avatar idle CPU budget); review inspected current #520 source/tests and current #514 stack state. No code changed in REVIEW mode.
blockers: HomeAssistantEventStream.run_forever() increments a process-lifetime backoff index on session-ending errors but does not reset it once auth + matching subscription acknowledgement + authoritative REST reconciliation have established a fresh session. Current lifecycle coverage locks in increasing delay across fully handshaken sessions instead of proving reset-after-recovery semantics. Formal REQUEST_CHANGES could not be submitted because the authenticated account owns the PR, so blocker is recorded as PR #520 conversation comment 5577008999. Prerequisite #514 currently reports mergeable/clean.
next_mode: IMPLEMENT
next_target: tests-first repair on PR #520: distinguish consecutive setup/session failures from an established fresh session and reset reconnect backoff only after auth + subscription success + authoritative reconciliation/freshness; then preserve stale/tombstone, cancellation, secret/origin, fresh-subscription-ID, packaged-runtime, and independent REST verification invariants and rerun exact-head gates.

WORKER_STATE mode_used: REVIEW result: BLOCKED — exact-head CI is green and packaged `websocket-client` runtime coverage is present, but reconnect backoff never resets after a fully established/fresh Home Assistant session; early failures can therefore leave all later reconnects paying the maximum delay even after recovery. issue_or_pr: #519 / PR #520 head: 45efd02d8c85f3c15578b26140cf671e6f49fec1 tests: exact-head GitHub Actions run 34168698910 completed green (`test` and `zara-avatar idle CPU budget`); review inspected current #520 source/tests and current #514 stack state. No code changed in REVIEW mode. blockers: `HomeAssistantEventStream.run_forever()` increments a process-lifetime backoff index on session-ending errors but does not reset it once auth + matching subscription acknowledgement + authoritative REST reconciliation have established a fresh session. Current lifecycle coverage locks in increasing delay across fully handshaken sessions instead of proving reset-after-recovery semantics. Formal REQUEST_CHANGES could not be submitted because the authenticated account owns the PR, so blocker is recorded as PR #520 conversation comment 5577008999. Prerequisite #514 currently reports mergeable/clean. next_mode: IMPLEMENT next_target: tests-first repair on PR #520: distinguish consecutive setup/session failures from an established fresh session and reset reconnect backoff only after auth + subscription success + authoritative reconciliation/freshness; then preserve stale/tombstone, cancellation, secret/origin, fresh-subscription-ID, packaged-runtime, and independent REST verification invariants and rerun exact-head gates.

nsaspy commented

2026-09-08 02:17:37 +00:00

Author

Owner

WORKER_STATE
worker: providers-home
mode_used: IMPLEMENT
result: Fixed PR #520 reconnect-backoff recovery semantics tests-first: backoff now resets only after a genuinely fresh Home Assistant event session (successful auth, subscription acknowledgement, and reconciliation), while pre-fresh failures continue to escalate bounded delays.
issue_or_pr: #519; PR #520; prerequisite PR #514
head: 1ccd1b9ce9
tests: RED-first lifecycle commit 1ffea071b9 changes the established-session expectation to [1.0, 1.0] and adds a pre-fresh failure case that must remain [1.0, 2.0]; implementation commit 1ccd1b9ce9 resets only after fresh=true. Exact-head CI run 34175185693 is pending; no green claim yet.
provider_tests: This slice specifically covers reconnect recovery vs failure escalation. Existing PR coverage remains responsible for auth/subscription ordering, bounded I/O, cancellation, stale/tombstone handling, packaged websocket-client import, plugin lifecycle, and REST reconciliation-before-fresh.
security: No credential/origin/capability boundary changed. Event state remains observation-only; independent REST read-back remains the only mutation verification authority. SmartThings credential/event authority remains in lost-rob0t/zara#202.
core_handoffs: lost-rob0t/zara#202 remains the SmartThings OAuth/device/event provider owner.
blockers: Exact-head CI 34175185693 must complete successfully before merge-readiness can be claimed. PR #520 remains stacked on prerequisite PR #514.
next_mode: REVIEW
next_target: Adversarial exact-head review of PR #520 at 1ccd1b9ce9: confirm CI, verify reset happens only after acknowledged+reconciled freshness, ensure auth/subscription/reconcile failures still escalate, and re-check cancellation, stale/tombstone fences, secret/origin confinement, packaged runtime, and #514 -> #520 stack readiness.

WORKER_STATE worker: providers-home mode_used: IMPLEMENT result: Fixed PR #520 reconnect-backoff recovery semantics tests-first: backoff now resets only after a genuinely fresh Home Assistant event session (successful auth, subscription acknowledgement, and reconciliation), while pre-fresh failures continue to escalate bounded delays. issue_or_pr: #519; PR #520; prerequisite PR #514 head: 1ccd1b9ce917ba66417f66d21409e8219d078322 tests: RED-first lifecycle commit 1ffea071b9eb620bb4fde6e444aefede54d349bc changes the established-session expectation to `[1.0, 1.0]` and adds a pre-fresh failure case that must remain `[1.0, 2.0]`; implementation commit 1ccd1b9ce917ba66417f66d21409e8219d078322 resets only after `fresh=true`. Exact-head CI run 34175185693 is pending; no green claim yet. provider_tests: This slice specifically covers reconnect recovery vs failure escalation. Existing PR coverage remains responsible for auth/subscription ordering, bounded I/O, cancellation, stale/tombstone handling, packaged websocket-client import, plugin lifecycle, and REST reconciliation-before-fresh. security: No credential/origin/capability boundary changed. Event state remains observation-only; independent REST read-back remains the only mutation verification authority. SmartThings credential/event authority remains in lost-rob0t/zara#202. core_handoffs: lost-rob0t/zara#202 remains the SmartThings OAuth/device/event provider owner. blockers: Exact-head CI 34175185693 must complete successfully before merge-readiness can be claimed. PR #520 remains stacked on prerequisite PR #514. next_mode: REVIEW next_target: Adversarial exact-head review of PR #520 at 1ccd1b9ce917ba66417f66d21409e8219d078322: confirm CI, verify reset happens only after acknowledged+reconciled freshness, ensure auth/subscription/reconcile failures still escalate, and re-check cancellation, stale/tombstone fences, secret/origin confinement, packaged runtime, and #514 -> #520 stack readiness.

nsaspy commented

2026-09-08 02:17:38 +00:00

Author

Owner

WORKER_STATE
worker: providers-home
mode_used: REVIEW
result: Cleared PR #520 reconnect-backoff correctness at exact head: exact-head CI is green, reset occurs only after acknowledged+reconciled fresh=true, pre-fresh failures still escalate, and no new provider/security/postcondition blocker was found in the event-stream slice.
issue_or_pr: #519; PR #520; prerequisite PR #514; review comment 5577983065
head: 1ccd1b9ce9
provider_tests: Exact-head CI run 34175185693 completed successfully at this SHA. Re-reviewed successful-session reset [1.0, 1.0] versus pre-fresh failure escalation [1.0, 2.0], auth/subscription gating, reconcile failure behavior, bounded I/O/reconnect, cancellation, stale/tombstone fences, authoritative reconnect membership eviction, plugin lifecycle, packaged websocket-client import, and preservation of independent REST mutation verification.
security: Same-origin WebSocket derivation and validated bearer boundary remain intact; no secret-bearing failure path found; event state remains observation-only and cannot authorize or verify mutations; SmartThings OAuth/device/event authority remains in lost-rob0t/zara#202.
core_handoffs: lost-rob0t/zara#202 remains the SmartThings server-side OAuth/device/event owner.
blockers: No new #520 code blocker relative to its exact #514 base. Stack integration is not yet proven against current main: #514 remains open and main has advanced to 89f0e938fb, so refresh/rebase #514 first, then #520, and rerun exact-head gates before merge. Real Home Assistant deployment/reverse-proxy behavior remains outside deterministic CI proof.
next_mode: IMPLEMENT
next_target: Refresh the #514 -> #520 stack onto current main without changing the bounded provider contracts; resolve only concrete conflicts, preserve tests-first history for feature changes, rerun full exact-head zara-home/registry/package/Nix/compatibility gates on the refreshed heads, and do not merge or commit directly to main.

WORKER_STATE worker: providers-home mode_used: REVIEW result: Cleared PR #520 reconnect-backoff correctness at exact head: exact-head CI is green, reset occurs only after acknowledged+reconciled `fresh=true`, pre-fresh failures still escalate, and no new provider/security/postcondition blocker was found in the event-stream slice. issue_or_pr: #519; PR #520; prerequisite PR #514; review comment 5577983065 head: 1ccd1b9ce917ba66417f66d21409e8219d078322 provider_tests: Exact-head CI run 34175185693 completed successfully at this SHA. Re-reviewed successful-session reset `[1.0, 1.0]` versus pre-fresh failure escalation `[1.0, 2.0]`, auth/subscription gating, reconcile failure behavior, bounded I/O/reconnect, cancellation, stale/tombstone fences, authoritative reconnect membership eviction, plugin lifecycle, packaged websocket-client import, and preservation of independent REST mutation verification. security: Same-origin WebSocket derivation and validated bearer boundary remain intact; no secret-bearing failure path found; event state remains observation-only and cannot authorize or verify mutations; SmartThings OAuth/device/event authority remains in lost-rob0t/zara#202. core_handoffs: lost-rob0t/zara#202 remains the SmartThings server-side OAuth/device/event owner. blockers: No new #520 code blocker relative to its exact #514 base. Stack integration is not yet proven against current main: #514 remains open and main has advanced to 89f0e938fbd57a13c58e597b2ef65c0d59b67810, so refresh/rebase #514 first, then #520, and rerun exact-head gates before merge. Real Home Assistant deployment/reverse-proxy behavior remains outside deterministic CI proof. next_mode: IMPLEMENT next_target: Refresh the #514 -> #520 stack onto current main without changing the bounded provider contracts; resolve only concrete conflicts, preserve tests-first history for feature changes, rerun full exact-head zara-home/registry/package/Nix/compatibility gates on the refreshed heads, and do not merge or commit directly to main.

nsaspy referenced this issue

2026-09-08 02:20:16 +00:00

Add zara-knowledge with first-class Brave Search provider #508