Files
JiboExperiments/OpenJibo/docs/prompts/cloud-deploy-and-jibo-rcm-path.md

55 lines
2.2 KiB
Markdown
Raw Normal View History

2026-04-18 16:29:27 -05:00
# Cloud Deploy And Jibo RCM Path Prompt
Prepare OpenJibo for a lightweight v1 cloud deployment and the cleanest practical Jibo configuration path for group testing.
Current repo context:
- workspace root: `.\OpenJibo`
2026-04-18 16:29:27 -05:00
- the current `.NET` cloud is the target runtime
- the Node server remains a discovery oracle and fallback
- latest live-test guidance is in:
- `docs/live-jibo-test-runbook.md`
- `docs/live-jibo-capture.md`
- `docs/device-bootstrap.md`
- `docs/development-plan.md`
- `src/Jibo.Cloud/dotnet/README.md`
What we need from this workstream:
1. define the smallest, cleanest, easiest-to-repeat deployment path for a v1 hosted OpenJibo cloud
2. define the lightest reliable way to configure Jibo devices to use that cloud, with as few manual error-prone steps as possible
3. produce scripts and docs that make it realistic for additional revival-group testers to get connected quickly
Important goals:
- prefer a path that is easy for non-experts in the revival group to follow
- minimize hand-edited device changes and confusing setup steps
- preserve a clear fallback path when a deployment or routing change fails
- keep the deployment practical for a small testing cohort first; enterprise polish can come later
Areas to review:
- current API host and routing logic in `src/Jibo.Cloud/dotnet/src/Jibo.Cloud.Api/Program.cs`
- existing scripts under:
- `scripts/cloud/`
- `scripts/bootstrap/`
- docs around routing and bootstrap in:
- `docs/device-bootstrap.md`
- `docs/live-jibo-test-runbook.md`
- `docs/live-jibo-capture.md`
Deliverables:
- a concrete v1 deployment recommendation
- any needed deployment scripts or setup helpers
- a clean Jibo configuration / routing / RCM procedure with the fewest practical steps
- validation steps that clearly distinguish cloud issues from robot/network issues
- doc updates aimed at making group adoption fast and low-risk
Constraints:
- do not over-design for full production scale yet
- avoid adding multiple competing deployment paths unless there is a strong reason
- optimize for reliability, repeatability, and low support burden for the next round of testers
- keep the Node oracle available as a troubleshooting fallback until `.NET` parity is clearly strong enough