Document commute provider seam for personal report
This commit is contained in:
24
OpenJibo/docs/calendar-architecture.md
Normal file
24
OpenJibo/docs/calendar-architecture.md
Normal file
@@ -0,0 +1,24 @@
|
||||
# Calendar Architecture
|
||||
|
||||
Pegasus treated calendar as a loop-scoped report surface, with report output fed by the
|
||||
household context instead of an isolated generic calendar service.
|
||||
|
||||
In OpenJibo, the current calendar path follows the same broad shape:
|
||||
|
||||
- calendar report output is loop-scoped
|
||||
- the report provider can read persisted loop calendar events
|
||||
- birthday and other personal dates already live in the loop-scoped holiday list
|
||||
- the personal report merges the report provider output into the spoken flow
|
||||
|
||||
Current behavior:
|
||||
|
||||
- if loop calendar events exist, the provider surfaces the next matching items
|
||||
- if no loop calendar events exist, the provider falls back to the merged holiday list
|
||||
- birthdays and custom holiday entries can therefore appear in the calendar section
|
||||
- the personal report still degrades safely when no calendar data is available
|
||||
|
||||
Notes:
|
||||
|
||||
- the current provider is intentionally lightweight and in-process
|
||||
- this gives us a swappable seam for later Azure-backed calendar sync
|
||||
- commute remains a separate report gap for the next pass
|
||||
72
OpenJibo/docs/commute-architecture.md
Normal file
72
OpenJibo/docs/commute-architecture.md
Normal file
@@ -0,0 +1,72 @@
|
||||
# Commute Architecture
|
||||
|
||||
## Purpose
|
||||
|
||||
Commute is part of personal report parity and household-aware personality.
|
||||
|
||||
The original Jibo report-skill had a commute section that could speak about getting to work, leaving soon, or being too early or too late. In OpenJibo, that behavior now starts with a loop-scoped commute profile so we can stay faithful to stock behavior first and add richer routing later.
|
||||
|
||||
## Current Shape
|
||||
|
||||
The cloud now models commute as persisted loop data instead of a hardcoded reply.
|
||||
|
||||
The current pieces are:
|
||||
|
||||
- `CommuteProfileRecord`
|
||||
- `ICommuteReportProvider`
|
||||
- `CloudStateCommuteReportProvider`
|
||||
- `Person/ListCommute`
|
||||
- `Person/UpsertCommute`
|
||||
|
||||
## Data Model
|
||||
|
||||
The commute profile is stored per loop and can optionally be tied to a person.
|
||||
|
||||
Typical fields include:
|
||||
|
||||
- `LoopId`
|
||||
- `MemberId`
|
||||
- `Mode`
|
||||
- `WorkHour`
|
||||
- `WorkMinute`
|
||||
- `OriginName`
|
||||
- `DestinationName`
|
||||
- `TypicalDurationMinutes`
|
||||
- `IsEnabled`
|
||||
- `IsComplete`
|
||||
|
||||
The provider uses the loop-scoped profile to decide whether commute is ready, missing setup, or ready to render a spoken answer.
|
||||
|
||||
## Runtime Behavior
|
||||
|
||||
At runtime, the commute provider:
|
||||
|
||||
- reads the current loop from the request context
|
||||
- loads the loop commute profile from cloud state
|
||||
- uses the profile plus current time to compute minutes until work
|
||||
- merges in same-day calendar pressure when a calendar event exists before the commute window
|
||||
- returns a safe setup response when the commute profile is missing or incomplete
|
||||
|
||||
## Personal Report Integration
|
||||
|
||||
Personal report uses the commute provider as a section in the broader household report.
|
||||
|
||||
That means the report can now speak in the familiar Jibo shape:
|
||||
|
||||
- weather
|
||||
- calendar
|
||||
- commute
|
||||
- news
|
||||
|
||||
## Next Gaps
|
||||
|
||||
The current commute provider is intentionally conservative.
|
||||
|
||||
Next steps can include:
|
||||
|
||||
- a richer travel-time source
|
||||
- map or transit integration
|
||||
- better depart-time commentary
|
||||
- preference-based commute suppression or reminders
|
||||
|
||||
For now the goal is to keep the interface stable and the behavior stock-like.
|
||||
@@ -44,6 +44,7 @@ Current release theme:
|
||||
- radio, ESML apostrophe cleanup, and first news are implemented in source/tests; radio and basic news are live-proven as of `jibo test 23`
|
||||
- `jibo test 22` validated radio, exposed backup/load interference, exposed a shared yes/no no-input gap, exposed repeated create keeper prompts after photo handoff, and showed local whisper `ffmpeg` failures on unusable buffered audio
|
||||
- `jibo test 23` validated basic news, proved one alarm set/fire path at `7:43 AM`, exposed comma-separated/short alarm follow-up parsing risk, showed stock alarm replacement yes/no rules that needed cloud handling, and showed photo gallery still failing when `shared/yes_no` ASR came back empty
|
||||
- personal report parity now has loop-scoped calendar and commute provider seams that merge persisted loop events, birthday/holiday dates, and commute profiles; the remaining report gap is richer travel-time data, not missing structure
|
||||
- `jibo test 24` showed alarm replacement yes/no working, but exposed empty `clock/alarm_set_value` and `gallery/gallery_preview` turns falling into generic `I heard you` fallback speech; it also showed `CLIENT_NLU cancel` inside `clock/alarm_set_value` re-asking for an alarm value instead of closing the prompt
|
||||
- `jibo test 25` proved a broader regression path but exposed repeated backup-in-progress/update-menu blockage, timer/alarm stale state and delete/menu disagreement, gallery `shared/yes_no` hangs under `@be/gallery`, punctuated `Never mind.` falling through to chat, volume homophone parsing (`Set Volume 2-6.`), and settings volume-control cleanup falling into `I heard you`
|
||||
- `jibo test 26` live-proved punctuated stop, volume homophone parsing, gallery launch/yes/create/save, and good morning; it still exposed robot-local backup warnings, long blue-ring buffering without a fresh `LISTEN`, alarm replacement drifting into the value/manual screen, and alarm delete phrases/mishears falling to chat
|
||||
@@ -731,7 +732,7 @@ Current release theme:
|
||||
- weather icon/animation parity and view support
|
||||
- broader non-local weather query handling and short-range date coverage
|
||||
- provider-backed news ingestion and filtering
|
||||
- commute provider path and settings schema
|
||||
- commute provider path, settings schema, and loop-scoped commute profile storage
|
||||
- coverage matrix for personal report parity gaps and test/capture exit criteria
|
||||
- Progress update (`2026-05-10`):
|
||||
- added provider-ready news briefing lane with Nimbus-compatible `news` skill payload continuity
|
||||
@@ -739,6 +740,7 @@ Current release theme:
|
||||
- fallback synthetic news behavior remains active when no provider key is configured
|
||||
- added TTL caching for weather/news provider calls to reduce repeated external requests
|
||||
- vendored Pegasus `report-skill` templates for weather and personal-report phrasing so the next pass can focus on renderer coverage for calendar, commute, and news templates instead of rediscovering source text
|
||||
- commute now has a loop-scoped provider seam plus persisted commute profiles, so the next pass can focus on richer travel-time data instead of basic storage shape
|
||||
- Source anchors:
|
||||
- `C:\Projects\jibo\pegasus\packages\report-skill\src\subskills\weather\WeatherMimLogic.ts`
|
||||
- `C:\Projects\jibo\pegasus\packages\report-skill\resources\views\weatherHiLo.json`
|
||||
@@ -927,7 +929,7 @@ For `1.0.19`:
|
||||
4. Weather report-skill launch compatibility - implemented
|
||||
5. Dialog parsing expansion and ambiguity guardrails - in progress (`2026-05-09` third guardrail slice implemented; Pegasus affinity phrase families + continuation guardrails expanded)
|
||||
6. Presence-aware greetings and identity-triggered proactivity - implemented (trigger path, identity-aware reactive/proactive replies, cooldown metadata wiring, focused websocket coverage)
|
||||
7. Personal report parity track (weather visuals, live news path, commute path, calendar parity matrix) - in progress (`2026-05-10` first live-news provider slice implemented)
|
||||
7. Personal report parity track (weather visuals, live news path, commute path, calendar parity matrix) - in progress (`2026-05-10` first live-news provider slice implemented; commute now has a loop-scoped provider seam)
|
||||
8. Holidays and seasonal personality behavior built on the new memory/proactivity foundation
|
||||
- system holidays should come from an up-to-date provider and merge with loop-scoped custom holiday records
|
||||
- allow disabled holiday records to suppress reminders for people who do not celebrate a holiday
|
||||
|
||||
@@ -120,6 +120,7 @@ Reference design:
|
||||
|
||||
- [persistence-architecture.md](persistence-architecture.md)
|
||||
- [holiday-architecture.md](holiday-architecture.md)
|
||||
- [commute-architecture.md](commute-architecture.md)
|
||||
|
||||
## First Implemented Slice In `1.0.19`
|
||||
|
||||
@@ -291,6 +292,10 @@ This confirms the pizza-fact offer state now keeps the yes/no branch open throug
|
||||
|
||||
Personal report parity planning is now captured with Pegasus source anchors for weather visuals/animations, live news, commute, and calendar gap coverage.
|
||||
|
||||
Calendar is now backed by a loop-scoped provider seam that can merge persisted loop events with birthday and holiday dates, keeping the report aligned with household context.
|
||||
|
||||
Commute now uses a loop-scoped commute profile and provider seam so the report can speak in the legacy commute shape without inventing a separate hosted travel service yet.
|
||||
|
||||
Reference:
|
||||
|
||||
- [personal-report-parity-plan.md](personal-report-parity-plan.md)
|
||||
@@ -335,7 +340,7 @@ Third completed guardrail slice under this queue:
|
||||
|
||||
Next queued implementation track after parser guardrails:
|
||||
|
||||
- personal report parity slices (weather visual parity, live news path, commute/calendar gap closure)
|
||||
- personal report parity slices (weather visual parity, live news path, commute/calendar refinement)
|
||||
|
||||
First completed slice in this personal-report parity track:
|
||||
|
||||
@@ -344,6 +349,7 @@ First completed slice in this personal-report parity track:
|
||||
- added memory/transcript category hinting for provider requests (`sports`, `technology`, `business`, etc.)
|
||||
- added provider-side request caching for both news and weather to reduce integration churn and repeated lookups
|
||||
- added focused interaction + websocket tests for provider-backed news speech output and request-hint plumbing
|
||||
- added loop-scoped calendar and commute provider seams so personal report can use persisted household context instead of static placeholders
|
||||
|
||||
## Next Slices
|
||||
|
||||
|
||||
Reference in New Issue
Block a user