FastyBird Smart Panel: shipped HomeKit gateway, then the command-window repair and unfinished acceptance

Question / brief (October 2, 2026). Can one inspect an agent-era feature from product request and implementation through human test, plan revision, related PRs and post-merge verification, instead of equating a merge with completion? A good answer connects a named feature and a reproduced defect to code, decisions, hardware and user-visible behavior, including human labor and later use. This follows the recent feature-trace brief and feature to outcome. Subquestions: (1) what original feature/agent role is actually evidenced? (2) where did a human or test revise the plan? (3) which patches merged and which measurable results belong to this defect? (4) did the user-level acceptance close, and how much human time did it require?

Primary source list and relationship. Adam Kadlec’s September 7 Studio81 firsthand workflow account describes architect → orchestrator → workers → independent reviewer, with GitHub epic/issues rather than worktrees as the durable coordination channel; it says Gemini via Antigravity implemented the HomeKit gateway, Codex reviewed repeatedly, then the team paired a real Apple Home bridge, tested UI and a simulator and deployed to a live installation. The corresponding public FastyBird Smart Panel PR #970 merged September 5: gateway and setup wizard, 29 commits, initial unit/type/build checks and several rounds of CodeRabbit review (a security/lifecycle group of findings received follow-up commits). This is evidence of the change and bot-review intervention, not a public agent session or human-hours ledger. The Studio81 article calls it a live installation but does not supply an independent customer’s outcome.

The same feature, later repair. The September 8 issue/technical plan #1006 begins with a manual Apple Home test on v1.1.0-alpha.4: a lamp switched new→old→new. It links evidence task #1007, identifies a virtual device projecting a Shelly source, and records five taps in 20 seconds: a previous command’s report was persisted 1.2 seconds after the next command was accepted; the observer located delay in the app’s write queue rather than the hardware, with 54 and 102 writes ahead in two instances. It compares backend command-window reconciliation against client-only settling and device-timestamp watermarks; it chooses the backend design to protect Apple Home, admin, panel and API consumers together. It documents an owner correction: initially proposed parallel tasks were changed to serial, maximum one implementing worker because shared hot-path files and lifecycle semantics overlapped. The new plan explicitly separates architecture (#1006), single orchestration handoff #1033 and operational/acceptance #1032, and states that a merge is not physical-system acceptance. This is a detailed public operating record, but the issue’s proposed targets are not automatically achieved results.

Patch trail and current observations. September 9 PR #1047 closes child issue #1010 and adds pending-write tokens, stale-value suppression and guarded rollback for the HomeKit characteristic cache, with regression tests. The issue itself says this HAP GET/cache hardening was not the original observed trigger: no HAP GET occurred in the reproduced window; the delayed backend report was. The plan records merged backend children for fast path, windows, stale readbacks, failed PATCH reconciliation and Shelly polling. September 27 PR #1120 is a further same-area repair: property metadata cache and opt-in cross-process value locks in a default one-backend installation, accepted-value reconciliation and HomeKit late-SET response behavior. Its author reports three command/restore cycles on an 111-device staging Raspberry Pi, client convergence 304–1067 ms and server report→publication 8–161 ms across six operations; full backend unit/E2E tests ran with disclosed warnings and environment gaps. The September 27 ledger readback verifies an unpublished review candidate on staging and says these are exploratory samples, not the required 20 idle + 20 actual-poll-overlap comparison, rapid-tap Apple Home/admin/panel recovery matrix or normal installed-worker upgrade. As checked October 2, #1006 and #1032 remain open. Caution: the issue body retains superseded September 25–26 instructions; prefer the timestamped September 27 readback to older ‘current’ text. Nor do October 2 unrelated backend PRs prove this issue closed.

What this changes. The agent-era architecture is less ‘more workers’ than public contract between product acceptance, issue orchestration and skeptical hardware validation. A firsthand September 7 account and linked public repo make this an unusually inspectable feature→repair chain; PRs and ledger narrow what shipped, where bot review contributed and why human testing still mattered. It does not provide agent session traces linking every patch to a model, active human planning/review/repair minutes, model spend or customer-confirmed repeated use. The deliberate switch to serial work is a concrete counterexample to default-parallel coordination; the validation ledger is a counterexample to treating green CI or a working three-cycle demo as a shipped user outcome. Compare Anghami’s single-operator plan memory and ParallelPilot’s 20-minute supervision blocks. Follow #1032 for an actual dated qualified matrix or a second real-use repair; keep separate hardware timing, client visibility, human attention and requester confirmation.