chore(harness): orient Makefile around iii engine config (playground-style)#135
Merged
Conversation
…style) Replace the bespoke build+spawn orchestration with a thin engine driver. Workers and per-worker config live in harness/config.yaml — the single source of truth the iii engine reads. The engine spawns each worker via its iii.worker.yaml scripts.start (cargo run for local Rust crates), so the Makefile no longer needs a hardcoded WORKERS array, _spawn-one helper, or per-worker config-file plumbing. harness/config.yaml: expand from 8 lines (iii-directory only) to a full playground-style manifest. Inline configs migrate from shell-config.yaml, iii-directory/config.yaml, and Makefile per-worker overrides. harness itself is registered with `worker_path: .` (relative — engine runs with harness/ as cwd, so state stores land under harness/data/). harness/Makefile: shrink from 229 to 113 lines. Drop `build`, `start`, `remote-install`, `_spawn-one`, WORKERS, REMOTE_WORKERS, BIN_NAME_FOR, per-worker pid/log files, and tmux. New `web` target backgrounds vite with a pidfile like the engine. Add `make lock` for refreshing iii.lock via `iii worker add .` when iii.worker.yaml changes. Delete: - harness/scripts/demo.sh (256-line bash duplicate of the Makefile) - harness/shell-config.yaml (inlined into config.yaml) - iii-directory/config.yaml (inlined into config.yaml)
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (19)
📝 WalkthroughWalkthroughThe PR migrates the demo harness from shell script orchestration to a Makefile-driven workflow. The ChangesHarness Workflow Refactor
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Contributor
skill-check — worker0 verified, 25 skipped (no docs/).
Three for three. Nicely done. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@harness/Makefile`:
- Line 30: DEMO_ENGINE_WS is computed from III_DEMO_ENGINE_URL but never used;
either remove the DEMO_ENGINE_WS assignment from the Makefile or wire it into
the build by templating config.yaml or passing it to the iii CLI invocations
used by the engine target (or related targets). If you want override support,
update the engine target to consume DEMO_ENGINE_WS (or export it) when invoking
iii or when rendering config.yaml; otherwise delete the DEMO_ENGINE_WS line to
avoid an unused variable.
🪄 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: ea441482-ee0f-4019-8b74-14c547f0fac2
📒 Files selected for processing (6)
harness/Makefileharness/README.mdharness/config.yamlharness/scripts/demo.shharness/shell-config.yamliii-directory/config.yaml
💤 Files with no reviewable changes (3)
- iii-directory/config.yaml
- harness/scripts/demo.sh
- harness/shell-config.yaml
The worker reads its own config from this file when run standalone. Was incorrectly deleted in the harness Makefile refactor.
…t it) config.yaml is now produced by `iii worker add .` on `make config` (invoked transitively by `make all` / `make engine`). The committed playground-style config is removed; each worker's own config.yaml (e.g., iii-directory/config.yaml) carries its overrides. Generated file gitignored. `make clean` removes it.
Drop the Makefile / local-demo / Expected-workers / contributor-link sections. Keep title+summary, Install (with mcp companion), Quickstart, Configuration. The README now answers the three required questions (what / install / first call) without dragging in source-build or development-process detail.
The web client moved to the WebSocket subscription path (registerWorker + on()) for live agent events. bridge::events had no production caller left — only the smoke test exercising it. Remove the handler, HTTP trigger registration, helper pump_events(), the sse module (its format_frame/heartbeat were only used here), and tests/sse_bridge.rs. Drop the events field from HarnessFunctionRefs. Update README, skill.md, ARCHITECTURE.md, and the lib.rs module doc that walked through the SSE discovery decision. bridge::trigger stays — still load-bearing for the bridge::info bootstrap fetch in iii-client.ts.
… harness/call) Function id moves into the harness:: namespace, matching harness::status and harness::fs::*. HTTP api_path renamed in lockstep (browser URL goes from POST /bridge/trigger to POST /harness/call). Vite proxy now forwards /harness instead of /bridge. Web: bridge.ts BRIDGE_URL, iii-client.ts bootstrap fetch, palette.ts curl snippet, palette.test.ts expectations, FunctionPalette comment, App.tsx footer tooltip. Docs: README, skill.md, ARCHITECTURE.md, skills/iii/iii.md, lib.rs module + BRIDGE_TIMEOUT_MS doc. policy-denylist comments updated for consistency. bridge::info stays — different function, only consumed by the harness itself during boot. Web cosmetic WIP in the working tree is left intact; only the rename hunks are staged.
Last bridge::* function moves into the harness namespace, matching harness::status / harness::call / harness::fs::*. Updates the handler registration, the iii-client.ts boot fetch body, comments, and renames tests/bridge_info.rs -> tests/harness_info.rs. Drops the now-dead "bridge::" prefix from FunctionPalette's PALETTE_HIDDEN_PREFIXES. After this commit, the bridge:: namespace is fully retired: - bridge::trigger -> harness::call (previous commit) - bridge::events -> deleted - bridge::info -> harness::info (this commit)
andersonleal
approved these changes
May 14, 2026
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary
harness/Makefile's build+spawn orchestration with a thin engine driver. The iii engine readsharness/config.yamland spawns each worker via its owniii.worker.yamlscripts.start(cargo runfor Rust workers — builds on demand).harness/config.yamlfrom 8 lines to a full playground-style manifest with inline per-worker config (shell denylist, iii-http port, iii-state path, etc.).harnessitself registers withworker_path: .— relative, so no machine paths in git.harness/Makefilefrom 229 → 113 lines. Remove the hardcodedWORKERSarray,_spawn-one,REMOTE_WORKERS,BIN_NAME_FORmacro, per-worker pid/log files, and tmux. Newwebtarget backgrounds vite with a pidfile.make lockrunsiii worker add .to refreshiii.lockwheniii.worker.yamlchanges (verified thatiii worker addpreserves pre-existing inlineconfig:blocks).harness/scripts/demo.sh(256-line bash duplicate of the Makefile),harness/shell-config.yaml, andiii-directory/config.yaml.Behavior change worth flagging
Today, every dep worker runs from local source (
cargo build --releaseper worker). After this PR, onlyharnessruns from local source; deps come from the registry per the versions inharness/iii.worker.yaml. Developers hacking on a sibling worker (e.g.,provider-router) need to either editharness/config.yamlto add aworker_path:line for that worker, or runiii worker add /path/to/siblingto inject one (it preserves existing inline configs).Test plan
cargo build+cargo test --libinharness/— 41/41 passmake clean && make all— engine boots,harness::statusreturns okmake web— vite serves on :5173 without tmux;make logs W=webtails it;make stopkills itmake restart— clean stop + restartSummary by CodeRabbit
Release Notes