Repository navigation
Add v3 UI screenshots to the README - #6
Conversation
Capture the four console tabs plus the running and manual-step job states against a demo 12-bottle cocktail profile, and document each in a new 'The UI' section. Co-authored-by: cmc0619 <cmc0619@users.noreply.github.com>
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 45 seconds Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (6)
📒 Files selected for processing (1)
Comment |
Greptile SummaryAdds a README gallery documenting the v3 touchscreen console.
Confidence Score: 4/5The PR appears safe to merge, though the README should not claim that STOP is reachable from every screen when it is confined to the Machine tab. The screenshot assets and relative links are present and valid, but one newly documented safety-related UI behavior contradicts the current tab layout. Files Needing Attention: README.md
|
| Filename | Overview |
|---|---|
| README.md | Adds the six-part UI walkthrough; the assertion that STOP remains reachable from every screen does not match the tab-scoped control. |
| docs/screenshots/dashboard-v3.png | Adds the Machine-tab screenshot referenced by the README. |
| docs/screenshots/menu-v3.png | Adds the Cocktails catalogue screenshot referenced by the README. |
| docs/screenshots/job-v3.png | Adds the active-pour screenshot referenced by the README. |
| docs/screenshots/job-manual-v3.png | Adds the manual-step screenshot referenced by the README. |
| docs/screenshots/inventory-v3.png | Adds the Inventory-tab screenshot referenced by the README. |
| docs/screenshots/settings-v3.png | Adds the Settings-tab screenshot referenced by the README. |
Reviews (1): Last reviewed commit: "Add v3 UI screenshots to README" | Re-trigger Greptile
| aligned, its slot established, and the machine armed; STOP stays reachable from | ||
| every screen. |
There was a problem hiding this comment.
Correct STOP availability claim
The STOP control is inside the Machine view, which is hidden when another tab is active, so claiming it stays reachable from every screen gives operators an inaccurate description of the safety UI.
| aligned, its slot established, and the machine armed; STOP stays reachable from | |
| every screen. | |
| aligned, its slot established, and the machine armed; STOP is available on | |
| this screen. |
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
* Document BarRobot v2 rewrite design * Rewrite BarRobot around testable services * Add BarRobot behavioral tests and CI * Fix package installation in CI * Design BarRobot v3 greenfield architecture * Replace legacy app with BarRobot v3 * Add isolated GPIO motion service * Add v3 tests deployment and CI * Add product and S-curve motion profiles * Add product changeover and party controls * Slow lopsided automatic moves * Add v2 UI screenshots to README (#5) Capture the five Flask pages plus the pour status list against a demo 12-bottle configuration in safe mode, and document each in a new 'The UI' section. Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: cmc0619 <cmc0619@users.noreply.github.com> * Add v3 UI screenshots to README (#6) Capture the four console tabs plus the running and manual-step job states against a demo 12-bottle cocktail profile, and document each in a new 'The UI' section. Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: cmc0619 <cmc0619@users.noreply.github.com> * Move the original Flask app into v1/ Makes room for the v2 and v3 implementations to live alongside it instead of replacing it. Co-authored-by: cmc0619 <cmc0619@users.noreply.github.com> * Index the three versions from the repository root Adds a root README explaining what v1, v2, and v3 are and which to use, merges the three .gitignore files, and splits CI into per-version workflows that only run when their own directory changes. Version READMEs now point at the shared LICENSE and hero image one level up. Co-authored-by: cmc0619 <cmc0619@users.noreply.github.com> * Raise v2's Flask and requests floors past known CVEs Codacy's dependency scanner resolves the lower bound of each constraint, so ">=3.1" and ">=2.32" were reported as vulnerable: Flask 3.1 CVE-2025-47278 session signing fallback key CVE-2026-27205 session data cached improperly requests 2.32 CVE-2024-47081 .netrc credential leak via crafted URLs CVE-2026-25645 predictable temporary file creation Both fixes land within the ranges the project already allows, so the floors move to the first patched releases and the upper bounds stand. ruff and the 31 tests pass against Flask 3.1.3 and requests 2.33.1. Co-authored-by: cmc0619 <cmc0619@users.noreply.github.com> * Configure Codacy for the three-version layout Codacy gates pull requests on new issues, and it decides what is new by path. Moving v1 into v1/ and bringing v2/ and v3/ onto main therefore presents both rewrites as brand-new code, so this PR inherits the whole backlog of the two open rewrite PRs at once: 62 issues from #2 plus 30 from #3, against a limit of zero. Four of those were real and are fixed in the preceding commit. The rest are analysers reaching wrong conclusions because they run with their own defaults rather than the configuration each version is built with: - Bandit reports B101 on every pytest assert and reads conftest.py's throwaway Flask signing key as a hardcoded password. - Codacy's ESLint has no access to v3's tsconfig, so it cannot see noUncheckedIndexedAccess and reports the undefined-guards that make v3 compile as conditions that are always false. - Opengrep flags a state repository whose path is configuration, and two innerHTML writes whose inputs are already escaped through the DOM's own textContent round-trip. - flawfinder flags every strncpy in motiond, all of which write memset-zeroed fixed buffers under an explicit sizeof - 1 bound. Each exclusion names one analyser and one path and carries its reason. No analyser is turned off repository-wide: v2's application code, 986 lines across eight files, stays under Bandit, and v3 keeps linting src/ in CI with typescript-eslint against the real tsconfig. Co-authored-by: cmc0619 <cmc0619@users.noreply.github.com> * Update v3's lockfile past nineteen dependency CVEs Codacy's dependency scanner reported these against package-lock.json. They are new since PR #3 was last analysed, not something the restructure introduced: @fastify/static 10.1.0 path traversal past route guards, and authorization bypass via non-canonical paths fastify 5.10.0 request spoofing through numeric trustProxy, and schema validation bypass on root primitives fast-uri 3.1.3, 4.1.0 six findings, mostly SSRF and host confusion from parsing inconsistencies find-my-way 9.6.0 HTTP/2 denial of service brace-expansion 5.0.7 denial of service through memory exhaustion Every fix was already inside the semver ranges package.json declares, so this is a lockfile refresh with no manifest change: fastify 5.12.3, @fastify/static 10.1.3, fast-uri 3.1.7 and 4.1.4, find-my-way 9.9.0, brace-expansion 5.0.9. npm audit is clean, npm ci reproduces the tree, and prettier, tsc, eslint, the build, and all 25 tests pass on it. Co-authored-by: cmc0619 <cmc0619@users.noreply.github.com> * Cover the remaining analysers that re-litigate v2 and v3 style The first pass cut Codacy's count on this PR from 92 to 45 and confirmed the exclusions land, but four analysers were named wrongly or not at all: - The strncpy findings in motiond come from Opengrep as well as flawfinder; only flawfinder was listed. - The 0.0001 objection in web/app.js is PMD's InnaccurateNumericLiteral, not ESLint, so excluding ESLint there had no effect. - Prospector and Pylint report twenty-two docstring and layout findings across v2 under a convention that contradicts the ruff configuration v2 actually enforces in CI. Each addition carries the same justification the existing entries do. Co-authored-by: cmc0619 <cmc0619@users.noreply.github.com> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: cmc0619 <cmc0619@users.noreply.github.com>
Screenshots of the v3 console, taken by running this branch. Targets
agent/barrobot-v3-greenfieldso they land inside PR #3 rather than onmain.Adds a The UI section to the README covering all four tabs plus both job states, with filenames suffixed
-v3.Machine
Cocktails
Manual step pause
The running-job, inventory, and settings shots are in the README.
How they were taken
enginesrequires), thennpm ci,npm run build, andnpm test— 25 tests pass.node dist/main.json port 5002 against its own state file.PUT /api/inventory: 12 bottles calibrated at 15 ml per press with aliases and fill estimates, plus 32 pantry items. 74 of 430 cocktails come out makeable.One caveat worth reading
barrobot-motiondcould not run here. It owns/dev/gpiochip0through Linux GPIO v2, and this container has no GPIO chip, no loadable modules, and no configfs, sogpio-simwas not an option either.Rather than photograph a permanently offline machine, I ran a small protocol-compatible stand-in on the Unix socket. It implements the same line protocol and mirrors the state machine in
motiond/src/motion.c— disarmed at startup with position unknown,ARMrefused until a position is established,SET_POSITIONrefused while armed,MOVE/DISPENSErefused while disarmed, busy during motion, andSTOPfaulting and invalidating position. Move and dispense durations are simulated so the queue advances at a believable pace.What this means for the screenshots:
Standardrather thanRT scheduledbecause the stand-in cannot obtainSCHED_FIFO. On a Pi running the packaged unit with its scheduling capability, that card should readRT scheduledafter the first move. That is the one field in these images that would look different on real hardware.The stand-in lives outside the repository and nothing about it is in this commit.
Notes
Only
README.mdanddocs/screenshots/change; no application code, andnpx prettier --check README.mdpasses.