Project AI advisor: investigation and authorized actions

Point permissions became the execution boundary: unbound points are neither read nor controlled; bound read-only points may support proposals requiring acceptance; explicitly controllable points may be operated directly. The backend must recheck authorization and retain constraints/auditing. Separate suggestion/execution modes were removed. Follow-up would review and remind rather than automatically reverse actions; device execution and effects were not verified.

Backend AI changes reportedly merged into local dev and passed tests. Related frontend/shared-module commits, tests and builds were reported complete with clean worktrees, but repositories remained unpushed. Changed response fields required paired frontend/backend releases. External services were unconfigured and browser/end-to-end checks unfinished. An AI-documentation inventory began without a final result.

Common UMS, mini-program and App notifications were discussed around authenticated HTTP retrieval. AI recommendation SMS would open a one-time confirmation page: merely opening it must not execute a device action; explicit acceptance or ignoring is required. Template configuration and backend tests were reported, while real receipt, phone-link behavior and test-device acceptance/ignore outcomes were still unknown.

The SMS confirmation page adopted a dark UI, organization identity, an optional project image and an orange primary action. Implementation began without final page acceptance. Backend/frontend development branches were reportedly pushed and synchronized, but production did not change. Migration, paired deployment and real-device checks remained separate.

Notification caching and foreground refresh changes reportedly passed tests/build but remained uncommitted. Real foreground/background behavior was unaccepted.

The advisor moved toward a single cloud-function scheduling path. Manual and automatic runs share a last-run-based interval, with a ten-minute minimum. Pending proposals are kept per point: a changed action replaces the old one, while an unchanged action extends its validity. The separate cooldown and per-run success-count cap were removed from the selected design, with one action per point per run retained. Implementation and test reports cover the models, commands and UI; they do not establish complete production execution.

A saved, sufficiently configured advisor can now be run manually while disabled. Description, point selection, AI configuration and entitlement checks remain. The UI reports that a request is queued rather than already started. One direct cloud-function attempt timed out on Redis before claiming its run. A later screen showed a successful run, but the evidence does not connect that success to a verified dependency repair. A test-environment migration also hit a timeout, with its final retry result uncaptured.

History retrieval was narrowed after a run consumed a large input context. Sensor summaries begin at the last successful run, ignore failed runs and cover between ten minutes and six hours; a first run uses six hours. Sampling, statistics and raw readings remain available when needed, while controllable points use operation and alert records. A read-only production query exposed the wrong value field; the corrected query returned data, followed by reports of 185 advisor tests and later 1,145 backend tests passing. The reorganized code was reportedly merged and pushed. Server and cloud-function deployment was still in progress. A separate interpretation error treated the summary-window start as gateway recovery time; its proposed wording repair had no final result.

In the evening, laan reported that an advisor run claimed to have switched an output off while the output still appeared on. An investigation was requested. No diagnosis, repair or repeat check is available, so the account retains the discrepancy without assigning a cause.

A Lambda-environment failure exposed missing MQTT connection settings. Laan requested alignment with production, without a captured applied configuration or verification. A later deployment-incident report attributed an unavailable Lambda to a package dependency difference. Server and another test environment reportedly completed migration and interface checks, but Lambda recovery, possible queued-message loss and real-account end-to-end refresh were unverified. No completed rollback or recovery appears in the retained record.

The reviewed conversation added reports of completed Lambda redeployment and passing Django regression tests. The earlier packaging failure was attributed to a corrupted dependency-download cache. Task loss or queue backlog could not be verified without queue access. Those reports do not certify real-account, database-tool and device paths end to end.

Advisor planning settled on one completion notification for a run affecting several points, with completed TODOs to be marked according to actual progress. Crop context was also discussed: existing project free text can provide context, but input guidance, prompts and structured data remained design questions. Laan sent a follow-up on that policy; no response, implementation or validation was captured.

A status review still listed unfinished real-environment tool, database and hardware checks, periodic-dispatch registration and a follow-up migration. Point limits, model cost and usage at a ten-minute cadence, quotas and runtime-version differences remained open. This was planning and status review, without a newly completed test, commit or deployment in the captured activity.