You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Build BarRobot v3 as a greenfield Pi controller - #3
Greenfield BarRobot v3 for the already-purchased Raspberry Pi, DM542T, NEMA-17, 12-slot turret, actuator, PSU, and existing GPIO wiring.
This PR is independent from v2 and targets main directly. It intentionally removes the Flask/Python implementation and does not preserve old routes, configuration files, recipe scaling, or module APIs.
Architecture
Node.js 24 LTS + strict TypeScript application
Fastify JSON API and dependency-free touchscreen UI
versioned atomic JSON persistence
explicit CocktailDB synchronization with ambiguous measures kept manual
calibrated inventory and dose-error validation
immutable drink plans and one FIFO job engine
manual-add pauses, cancellation, restart failure semantics, and out-of-band stop
native C11 barrobot-motiond process that exclusively owns GPIO through Linux GPIO v2
Unix socket boundary between HTTP/application code and motion code
No additional controller board or other hardware is required.
Motion and safety
startup is disarmed with actuator low, step low, driver disabled, and position unknown
operator-established position is required because the existing hardware has no implemented home sensor
exact slot boundaries distribute all 1,600 microsteps around 12 positions
shortest-path movement with clockwise tie-break and configurable ramps
Your recent review volume is higher than typical usage, so adaptive limits are currently applied.
Next review available in:37 seconds
Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).
How can I continue?
After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.
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.
Reviewing files that changed from the base of the PR and between af4f921 and 7f47f17.
⛔ Files ignored due to path filters (6)
docs/screenshots/dashboard-v3.png is excluded by !**/*.png
docs/screenshots/inventory-v3.png is excluded by !**/*.png
docs/screenshots/job-manual-v3.png is excluded by !**/*.png
docs/screenshots/job-v3.png is excluded by !**/*.png
docs/screenshots/menu-v3.png is excluded by !**/*.png
docs/screenshots/settings-v3.png is excluded by !**/*.png
📒 Files selected for processing (24)
README.md
deploy/barrobot-motion.service
docs/design-v3.md
motiond/include/motion.h
motiond/src/motion.c
motiond/src/server.c
motiond/tests/test_motion.c
src/adapters/cocktaildb-source.ts
src/adapters/motion-socket-client.ts
src/adapters/state-validation.ts
src/application/barrobot-service.ts
src/application/ports.ts
src/domain/model.ts
src/domain/planner.ts
src/domain/seed.ts
src/http/server.ts
src/main.ts
tests/adapters.test.ts
tests/helpers.ts
tests/planner.test.ts
tests/service.test.ts
web/app.js
web/index.html
web/styles.css
Walkthrough
BarRobot v3 replaces the legacy Flask application with a TypeScript HTTP service, C motion daemon, Unix-socket protocol, validated JSON state, job orchestration, static browser UI, systemd deployment, and CI coverage for application and motion builds.
Extract shared default constants for pressDurationMs and releaseDurationMs.
These values are hardcoded identically in both addInventory (lines 212–213) and saveInventory (lines 243–244). If defaults change, both must be updated in sync.
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@web/app.js` around lines 203 - 247, Extract shared constants for the default
press and release durations, then replace the duplicated 600 and 200 literals in
both addInventory and saveInventory with those constants. Keep the existing
values and behavior unchanged.
Consider Promise.allSettled for resilient free-tier sync.
fetchFree fires 26 parallel requests to the CocktailDB free API. A single rate-limited response (HTTP 429) or transient failure causes Promise.all to reject, failing the entire sync. Using Promise.allSettled and filtering fulfilled results would allow partial sync completion, letting the operator retry only the failed letters.
♻️ Proposed refactor for resilient free-tier fetching
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/adapters/cocktaildb-source.ts` around lines 36 - 43, Update fetchFree to
use Promise.allSettled for the per-letter CocktailDB requests, then retain only
fulfilled results before flattening their drinks arrays. Preserve the existing
letter iteration and empty-drinks fallback while allowing individual rate-limit
or transient failures to be skipped.
Call motion_destroy and gpio_linux_destroy on shutdown.
The (void)motion; (void)gpio; suppressions indicate these are intentionally not cleaned up. While motion_stop (called by the signal thread) sets safe outputs and the kernel releases GPIO on process exit, gpio_linux_destroy is documented to "restore safe output values and release the GPIO line request" and motion_destroy destroys the mutex. Explicit cleanup ensures proper resource release and safe GPIO teardown.
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@motiond/src/server.c` around lines 121 - 125, Replace the unused-variable
suppressions in the shutdown path after pthread_join with calls to
motion_destroy for motion and gpio_linux_destroy for gpio, before unlinking the
socket and returning. Preserve the existing shutdown ordering so the signal
thread has finished before destroying these resources.
Consider adding tests for disarm, reset, invalid slot, and BUSY rejection.
The current tests cover startup, arm, full revolution, tie-breaking, dispense, and stop — the most critical safety paths. Missing cases include: motion_disarm output behavior, motion_reset fault recovery, invalid slot rejection (MOTION_INVALID), and concurrent command rejection (MOTION_BUSY). Adding these would strengthen confidence in the state machine's edge cases.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@motiond/tests/test_motion.c` around lines 63 - 128, Add focused tests
alongside the existing motion tests for the missing state-machine cases: verify
motion_disarm’s return value and GPIO output behavior, confirm motion_reset
recovers from a latched fault, assert invalid slot commands return
MOTION_INVALID without changing state, and exercise an in-progress command to
ensure concurrent commands return MOTION_BUSY. Register each new test in main,
reusing the existing fake_gpio and motion lifecycle patterns.
If file.sync() or writeFile throws, the finally block closes the handle but never unlinks temporary, leaving orphaned .tmp files in the state directory. Over time a flaky disk could accumulate stale temp files. Consider cleaning up in a catch/finally.
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/adapters/json-state-repository.ts` around lines 38 - 56, Update
writeAtomic to remove the temporary file when writeFile or file.sync fails,
while still closing the file handle and preserving the existing rename path on
success. Use the existing temporary variable and ensure cleanup errors do not
replace the original write failure.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@deploy/barrobot.service`:
- Line 16: Update the BARROBOT_HOST setting in the service configuration to bind
the actuator API only to loopback, preserving local touchscreen access without
exposing unauthenticated control endpoints on every network interface.
In `@motiond/src/server.c`:
- Around line 98-121: Ensure the accept loop’s non-EINTR error path also
terminates the signal thread before joining it: use pthread_kill with the
already-blocked SIGTERM signal to wake sigwait, then proceed to
pthread_join(signal_thread, NULL). Preserve the existing EINTR retry and normal
shutdown behavior.
In `@scripts/install.sh`:
- Around line 26-28: Update the service activation commands in
scripts/install.sh to separate enabling from restarting for
barrobot-motion.service and barrobot.service. Replace the --now behavior with
explicit systemctl enable followed by systemctl restart so newly installed
binaries are activated on both initial installation and upgrades.
In `@src/application/barrobot-service.ts`:
- Around line 221-270: Move the initial persist call in runJob into the try
block so activeJobId is always cleared by finally when persistence fails. Ensure
the failure-handling persist in runJob’s catch cannot throw an unhandled
rejection, and add rejection handling to pump so asynchronous job-processing
failures are contained. Preserve the existing job failure status updates and
cleanup behavior.
In `@src/http/server.ts`:
- Around line 39-61: Update the catch fallback in the /api/status handler to
derive queuedJobs and activeJob from the existing state snapshot, matching the
successful return branch. Preserve the offline motion response, but do not
replace snapshot-derived job information with zero or null when service.status()
fails.
In `@web/app.js`:
- Around line 169-184: Update the data-mode attribute interpolation in
renderInventory to pass item.mode through escapeAttribute, matching the escaping
used for other user-controlled attribute values while preserving the existing
mode selection behavior.
In `@web/index.html`:
- Around line 135-149: The deployed UI must not present motionSocket,
listenHost, and listenPort as immediately effective settings. Remove or disable
these inputs in web/index.html, or clearly mark them as requiring a systemd
service-unit change and service restart; preserve the maxDoseErrorPercent field.
---
Nitpick comments:
In `@motiond/src/server.c`:
- Around line 121-125: Replace the unused-variable suppressions in the shutdown
path after pthread_join with calls to motion_destroy for motion and
gpio_linux_destroy for gpio, before unlinking the socket and returning. Preserve
the existing shutdown ordering so the signal thread has finished before
destroying these resources.
In `@motiond/tests/test_motion.c`:
- Around line 63-128: Add focused tests alongside the existing motion tests for
the missing state-machine cases: verify motion_disarm’s return value and GPIO
output behavior, confirm motion_reset recovers from a latched fault, assert
invalid slot commands return MOTION_INVALID without changing state, and exercise
an in-progress command to ensure concurrent commands return MOTION_BUSY.
Register each new test in main, reusing the existing fake_gpio and motion
lifecycle patterns.
In `@src/adapters/cocktaildb-source.ts`:
- Around line 36-43: Update fetchFree to use Promise.allSettled for the
per-letter CocktailDB requests, then retain only fulfilled results before
flattening their drinks arrays. Preserve the existing letter iteration and
empty-drinks fallback while allowing individual rate-limit or transient failures
to be skipped.
In `@src/adapters/json-state-repository.ts`:
- Around line 38-56: Update writeAtomic to remove the temporary file when
writeFile or file.sync fails, while still closing the file handle and preserving
the existing rename path on success. Use the existing temporary variable and
ensure cleanup errors do not replace the original write failure.
In `@web/app.js`:
- Around line 203-247: Extract shared constants for the default press and
release durations, then replace the duplicated 600 and 200 literals in both
addInventory and saveInventory with those constants. Keep the existing values
and behavior unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
Push a commit to this branch (recommended)
Create a new PR with the fixes
ℹ️ Review info⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: b179f12e-80c4-4bab-8888-939cd34029f9
📥 Commits
Reviewing files that changed from the base of the PR and between affb9ad and af4f921.
⛔ Files ignored due to path filters (3)
classes.dot is excluded by !**/*.dot
package-lock.json is excluded by !**/package-lock.json
The reason will be displayed to describe this comment to others. Learn more.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Do not expose the actuator API unauthenticated.
Line 16 binds the service to every interface, while the API permits arm, move, dispense-job, and stop actions without authentication. The origin hook is not network access control. Bind to loopback for the local touchscreen, or put remote access behind authenticated TLS and firewall rules.
‼️IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
Environment=BARROBOT_HOST=0.0.0.0
Environment=BARROBOT_HOST=127.0.0.1
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@deploy/barrobot.service` at line 16, Update the BARROBOT_HOST setting in the
service configuration to bind the actuator API only to loopback, preserving
local touchscreen access without exposing unauthenticated control endpoints on
every network interface.
Potential deadlock if accept4 fails for a non-signal reason.
If accept4 returns an error other than EINTR that is not caused by the signal thread's shutdown (e.g., EMFILE from too many open file descriptors), the main thread breaks out of the loop and calls pthread_join(signal_thread, NULL). Since the signal thread is still blocked in sigwait, this join blocks indefinitely. Consider sending a signal to the signal thread or using pthread_cancel before the join.
Since SIGTERM is already in the blocked signal set and sigwait will catch it, pthread_kill unblocks the signal thread cleanly.
📝 Committable suggestion
‼️IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
if (pthread_create(&thread, NULL, handle_client, context) !=0) {
close(client_fd);
free(context);
continue;
}
pthread_detach(thread);
}
pthread_kill(signal_thread, SIGTERM);
pthread_join(signal_thread, NULL);
unlink(config.socket_path);
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@motiond/src/server.c` around lines 98 - 121, Ensure the accept loop’s
non-EINTR error path also terminates the signal thread before joining it: use
pthread_kill with the already-blocked SIGTERM signal to wake sigwait, then
proceed to pthread_join(signal_thread, NULL). Preserve the existing EINTR retry
and normal shutdown behavior.
Use restart instead of --now to pick up new binaries on upgrade.
systemctl enable --now starts services on first install but does not restart already-running services. On a re-run (upgrade), the new binary is on disk while the old process keeps running. Separating enable from restart ensures the new binary is activated on both first install and upgrade.
‼️IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
systemctl --no-pager --full status barrobot-motion.service barrobot.service
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@scripts/install.sh` around lines 26 - 28, Update the service activation
commands in scripts/install.sh to separate enabling from restarting for
barrobot-motion.service and barrobot.service. Replace the --now behavior with
explicit systemctl enable followed by systemctl restart so newly installed
binaries are activated on both initial installation and upgrades.
The reason will be displayed to describe this comment to others. Learn more.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Preserve job state when motion status is unavailable.
If service.status() fails, the fallback reports no queued or active job even when the snapshot already contains one. A temporary daemon outage can therefore hide a waiting-manual drink and its cancel/continue controls. Return the snapshot-derived queue and active job in both branches.
‼️IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
error: errorinstanceofError ? error.message : "Motion service offline",
},
queuedJobs,
activeJob,
};
}
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/http/server.ts` around lines 39 - 61, Update the catch fallback in the
/api/status handler to derive queuedJobs and activeJob from the existing state
snapshot, matching the successful return branch. Preserve the offline motion
response, but do not replace snapshot-derived job information with zero or null
when service.status() fails.
The reason will be displayed to describe this comment to others. Learn more.
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
Escape item.mode in the data-mode attribute.
Line 173 interpolates item.mode directly into an HTML attribute without escapeAttribute, unlike all other user-controlled values in this template. While the server validates mode to "bottle" or "pantry", defense-in-depth requires escaping it consistently.
‼️IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@web/app.js` around lines 169 - 184, Update the data-mode attribute
interpolation in renderInventory to pass item.mode through escapeAttribute,
matching the escaping used for other user-controlled attribute values while
preserving the existing mode selection behavior.
The reason will be displayed to describe this comment to others. Learn more.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Do not present deployment-overridden settings as effective.
These fields save successfully, but production always overrides motionSocket, listenHost, and listenPort through systemd environment variables. The socket value is therefore never used, and host/port are also only read at startup. Remove or disable these fields in the deployed UI, or explicitly show that they require a service-unit change/restart.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@web/index.html` around lines 135 - 149, The deployed UI must not present
motionSocket, listenHost, and listenPort as immediately effective settings.
Remove or disable these inputs in web/index.html, or clearly mark them as
requiring a systemd service-unit change and service restart; preserve the
maxDoseErrorPercent field.
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>
BarRobot v3 replaces the legacy Flask controller with a TypeScript application and isolated native motion daemon.
Adds calibrated recipe planning, persistent inventory profiles, and a FIFO drink-job engine.
Adds a Fastify API and dependency-free touchscreen interface.
Adds Linux GPIO v2 motion control, Unix-socket communication, deployment units, installation tooling, and CI coverage.
Confidence Score: 3/5
This PR should not merge until concurrent stop and disarm requests are guaranteed to prevent the dispense loop from re-energizing the actuator.
The independently handled motion commands leave a check-to-assert race in the core safety path, allowing the actuator to turn back on after STOP or DISARM has reported success.
Files Needing Attention: motiond/src/motion.c and motiond/src/server.c
Important Files Changed
Filename
Overview
motiond/src/motion.c
Implements motion safety and dispensing, but stop/disarm can race with actuator assertion during an active dispense.
motiond/src/server.c
Implements the concurrent Unix-socket command server and exposes the stop/dispense concurrency underlying the motion race.
src/application/barrobot-service.ts
Adds persisted FIFO job orchestration, cancellation, manual pauses, and restart failure handling.
src/http/server.ts
Adds the JSON API, same-origin mutation checks, static UI serving, and application-service routing.
src/domain/planner.ts
Adds calibrated immutable drink planning with automatic and manual ingredient steps.
motiond/src/gpio_linux.c
Adds exclusive Linux GPIO v2 line ownership and raw line operations for the motion controller.
scripts/install.sh
Builds and installs the application, native daemon, state directory, service account, and systemd units.
Sequence Diagram
sequenceDiagram
participant App as TypeScript application
participant Server as Motion socket server
participant Motion as Motion controller
participant GPIO as Linux GPIO v2
App->>Server: DISPENSE
Server->>Motion: motion_dispense()
Motion->>GPIO: actuator and motion outputs
App->>Server: STOP (separate connection)
Server->>Motion: motion_stop()
Motion->>GPIO: safe outputs
The reason will be displayed to describe this comment to others. Learn more.
Stop race reasserts actuator
When STOP or DISARM runs after the dispense loop checks stop_requested and armed but before it asserts the actuator, the safety command clears the outputs and returns success before the dispense thread energizes the actuator again, causing it to remain active for up to the configured 60-second press duration.
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
While the architectural transition to Node.js and a native C11 daemon is sound and covers all primary acceptance criteria, the PR is currently not up to standards. A critical security risk was identified in the motion daemon's socket handling where unsafe string copying could lead to buffer overflows or non-terminated strings.
Furthermore, the implementation of external API fetching is likely to trigger rate limits, and there is a misalignment between the documented safety slowdown percentages and the actual multipliers used in the service logic. Core modules like motion.c and state-validation.ts exhibit very high complexity, which may impact future maintainability despite the presence of automated tests.
About this PR
The PR has introduced 30 new quality issues and is currently flagged as not up to standards. Please review the specific findings in the file comments to address these regressions.
Test suggestions
Found recommended test scenario: Verify exact 1,600 step revolution counts via fake GPIO backend
Found recommended test scenario: Verify S-curve ramp starts without initial velocity jumps
Found recommended test scenario: Verify shortest path logic with clockwise tie-break on 6-slot moves
Found recommended test scenario: Verify arming is rejected until position is established
Found recommended test scenario: Verify stop command latches fault and invalidates turret position
Found recommended test scenario: Verify measure parsing for volume (ml) vs. manual terms (e.g., 'wedge')
Found recommended test scenario: Verify recipe rejection when dose error exceeds configured tolerance
Found recommended test scenario: Verify FIFO job execution correctly pauses for manual acknowledgement
Found recommended test scenario: Verify cross-origin POST requests are rejected at the HTTP boundary
Found recommended test scenario: Verify atomic state replacement and version validation during persistence
Low confidence findings
Several core files, including motiond/src/motion.c (complexity: 145) and src/adapters/state-validation.ts (complexity: 132), exhibit high cyclomatic complexity. While these implement critical logic, consider refactoring them into smaller, more testable units in a follow-up PR.
The reason will be displayed to describe this comment to others. Learn more.
🟡 MEDIUM RISK
Suggestion: The application triggers up to 26 concurrent HTTP requests to CocktailDB. This is likely to be rate-limited by the service.
Try running the following prompt in your coding agent:
In src/adapters/cocktaildb-source.ts, refactor fetchFree to fetch the batches sequentially using a loop instead of Promise.all to respect external API limits.
The reason will be displayed to describe this comment to others. Learn more.
🟡 MEDIUM RISK
Nitpick: The 'multiplier' is guaranteed to be defined because the preceding regex match only allows units that exist in the UNIT_TO_ML map. The undefined check can be removed for cleaner logic.
The reason will be displayed to describe this comment to others. Learn more.
🟡 MEDIUM RISK
Nitpick: This condition is unnecessary because 'step' is guaranteed to be defined for every iteration within the array bounds.
Try running the following prompt in your IDE agent:
Remove the redundant if (!step) check and the associated error throwing from src/application/barrobot-service.ts around line 277, as the loop bounds guarantee the element exists.
The reason will be displayed to describe this comment to others. Learn more.
⚪ LOW RISK
Suggestion: The timing multipliers (125, 150) result in a 20% and 33% speed reduction respectively (1/1.25 and 1/1.5). To achieve the 50% slowdown mentioned in the description, a timing multiplier of 200 would be required.
The reason will be displayed to describe this comment to others. Learn more.
⚪ LOW RISK
Nitpick: The motion and gpio objects are not explicitly destroyed on exit. Calling the destroyers ensures clean closure of file descriptors and state.
Try running the following prompt in your coding agent:
In motiond/src/server.c, replace the (void) casts at the end of main with calls to motion_destroy(motion) and gpio_linux_destroy(gpio) after the signal thread has joined.
cursorBot
pushed a commit
that referenced
this pull request
Sep 7, 2026
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>
cursorBot
pushed a commit
that referenced
this pull request
Sep 7, 2026
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>
* 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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![codacy-production[bot]](https://avatars.githubusercontent.com/in/56611?s=60&v=4){kind=small}
Summary
Greenfield BarRobot v3 for the already-purchased Raspberry Pi, DM542T, NEMA-17, 12-slot turret, actuator, PSU, and existing GPIO wiring.
This PR is independent from v2 and targets
maindirectly. It intentionally removes the Flask/Python implementation and does not preserve old routes, configuration files, recipe scaling, or module APIs.Architecture
barrobot-motiondprocess that exclusively owns GPIO through Linux GPIO v2No additional controller board or other hardware is required.
Motion and safety
CLOCK_MONOTONICdeadlines prevent accumulated timer driftSCHED_FIFOstatus is reported honestlyDeployment
barrobot-motion.serviceandbarrobot.servicebarrobotaccount with only the existing Pigpiogroup and motion scheduling capability/opt/barrobot/var/lib/barrobot/state.jsonValidation
-Wall -Wextra -Werror -Wpedantic -Wconversion -WshadowSee
docs/design-v3.mdfor the complete design and safety contract.Summary by CodeRabbit
New Features
Documentation
Tests