fixes for clock and photo gallery

OpenJibo/docs/development-plan.md

@@ -182,13 +182,19 @@ Latest clock discovery findings:
 - `@be/clock` is a real local skill with `clock`, `timer`, and `alarm` domains.
 - Menu launches use `intent = "menu"` with `entities.domain` set to the target sub-area.
 - Direct timer and alarm actions use `timerValue` and `alarmValue` utterances, not a generic chat path.
-- A practical first OpenJibo slice is therefore: keep custom spoken time/date answers for now, but route `open clock`, `open timer`, `open alarm`, `set a timer ...`, and `set an alarm ...` through stock-shaped local `@be/clock` handoffs.
+- The newest `.NET` pass now routes `open the clock` into the direct `askForTime` clock-view path, moves plain time/date/day questions onto stock-shaped local `@be/clock` handoffs, and keeps malformed timer/alarm requests on a clarification reply path instead of generic chat echo.
 
 Latest photo discovery findings:
 
 - `@be/gallery` is the local gallery browser and opens from `intent = "menu"`.
 - `snapshot` and `photobooth` are not gallery submodes; stock main-menu logic remaps them into `@be/create` with `createOnePhoto` and `createSomePhotos`.
-- A practical first OpenJibo photo slice is therefore: route `open photo gallery` to `@be/gallery`, route `snap a picture` to `@be/create/createOnePhoto`, and route `open photobooth` to `@be/create/createSomePhotos`.
+- The newest `.NET` pass keeps that routing, adds local-file persistence for media metadata, and serves stored media URLs back through `/media/{path}` as a first hosted-gallery slice.
+- The remaining gap is binary fidelity: the current HTTP capture path stores request bodies as text, which is enough to preserve metadata and a placeholder payload, but may still be too lossy for perfect thumbnails/original fetches.
+
+Latest update and state findings:
+
+- unstaged update queries should not fabricate placeholder no-op manifests, because stock settings logic can treat any returned object like a pending update
+- the hosted `.NET` cloud now persists update/media/backups state to a local state file by default, which is a better bridge toward Azure SQL / Blob storage than the old process-memory-only behavior
 
 ## Speech, Animation, And ESML
 

OpenJibo/docs/feature-backlog.md

@@ -132,9 +132,10 @@ Parallel tags:
   - compare our custom time/date path against actual menu payloads
   - decide whether timer and alarm should stay robot-local with cloud acknowledgement, or whether cloud needs to shape the launch and follow-up turns
 - Progress so far:
-  - voice `open clock`, `open timer`, and `open alarm` now synthesize stock-shaped local `@be/clock` launches
-  - voice `set a timer for five minutes` and `set an alarm for 7:30 am` now emit direct `timerValue` / `alarmValue` payloads with the domain and value entities the local skill expects
-  - time/date remain on the existing custom cloud reply path for now
+  - voice `open the clock` now routes to the direct local `askForTime` clock-view path instead of the broader clock menu
+  - voice `what time is it`, `what's today's date`, and `what day is it` now use stock-shaped local `@be/clock` handoffs instead of custom cloud-only speech
+  - voice `set a timer for five minutes`, `set an alarm for 7:30 am`, `set an alarm for 830`, and `set an alarm for 8 30` now emit direct `timerValue` / `alarmValue` payloads with the entities the local skill expects
+  - partial timer/alarm requests such as `set a timer` and `set an alarm` now stay on a controlled clarification reply path instead of drifting into Nimbus/chat echo
 - Exit criteria:
   - time/date behavior stays correct
   - timer and alarm launch or set correctly from both menu and voice where applicable
@@ -158,10 +159,13 @@ Parallel tags:
   - voice `open photo gallery` now launches local `@be/gallery` with a stock-shaped `menu` handoff
   - voice `snap a picture` now launches local `@be/create` with `createOnePhoto`
   - voice `open photobooth` now launches local `@be/create` with `createSomePhotos`
+  - media and update metadata now persist to a local state file in the hosted `.NET` path, so gallery and staged update state are no longer strictly process-memory-only
+  - `Media.Create` now retains uploaded metadata plus a best-effort raw body placeholder and serves the same media URL back through `/media/{path}`
 - Open questions:
   - whether stock Jibo treats captured media as a short-lived local cache until cloud upload completes
   - what binary upload path and metadata are needed so gallery content persists instead of aging out locally
   - whether hosted OpenJibo should store originals, thumbnails, or both
+  - whether the current lossy HTTP body capture is enough for stock gallery thumbnails, or whether we need a binary-safe upload persistence path next
 - Exit criteria:
   - known photo menu and voice phrases map to the correct local path
   - capture storage expectations are documented for laptop versus hosted testing
@@ -179,6 +183,9 @@ Parallel tags:
   - inspect how OpenJibo advertises update manifests so the robot does not repeatedly think an update exists when nothing meaningful is pending
   - prove one successful backup path, one successful update delivery path, and one successful restore path
   - document the operator steps, risk boundaries, and recovery expectations before broader rollout
+- Latest progress:
+  - unstaged update queries no longer fabricate a placeholder no-op manifest, which should reduce the phantom `always has updates` behavior during normal operation
+  - real staged updates can still be created explicitly through the protocol layer when we are ready to prove end-to-end delivery
 - Exit criteria:
   - no phantom "always has updates" behavior in normal operation
   - one controlled update can be delivered successfully