Conversation
📝 WalkthroughSummary by CodeRabbitDocumentation
WalkthroughThis PR refocuses AgentRemote's documentation from a "universal remote for agents" to a "bridge layer" connecting Beeper/Matrix chat to self-hosted agent runtimes. Multiple README files and specification documents were updated to reflect the new directionality, simplify descriptions, and consolidate content across the repository. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (2 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/bridge-orchestrator.md`:
- Around line 15-17: Replace the insecure example that passes a bearer token on
the command line (the `./tools/bridges auth set-token --token ... --env prod`
usage) with a safer pattern: show using an environment variable (e.g., export
BRIDGE_TOKEN=...), a prompt/interactive flow (e.g., `./tools/bridges auth
set-token` which prompts for the token), or reading from a protected file (e.g.,
`./tools/bridges auth set-token --file /path/to/secret`), and make one of those
the primary example while keeping a note about avoiding `--token` on the command
line; update the docs lines that mention `./tools/bridges auth set-token
--token` and any help text recommending `--token` to instead reference
`BRIDGE_TOKEN`, interactive prompt, or `--file`.
In `@docs/msc/com.beeper.mscXXXX-streaming.md`:
- Around line 61-63: The doc currently says "`seq` is strictly positive and
monotonic per turn" which is ambiguous; update the wording to explicitly require
that `seq` is strictly increasing (i.e., each subsequent `seq` value for the
same `turn_id` must be greater than the previous one), and keep the other
constraints (`turn_id` is required, `part` is required) unchanged so clients
know to reject non-increasing or equal `seq` values.
🪄 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: 02f2b442-f608-4831-a6a7-dc396781df8c
📒 Files selected for processing (9)
README.mdbridges/codex/README.mdbridges/openclaw/README.mdbridges/opencode/README.mddocs/bridge-orchestrator.mddocs/matrix-ai-matrix-spec-v1.mddocs/msc/com.beeper.mscXXXX-commands.mddocs/msc/com.beeper.mscXXXX-ephemeral.mddocs/msc/com.beeper.mscXXXX-streaming.md
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Lint
- GitHub Check: build-docker
- GitHub Check: build-docker
🔇 Additional comments (10)
bridges/opencode/README.md (1)
1-39: Clear and consistent bridge-mode documentation.The mode split (
remotevsmanaged) and login prompts are easy to follow, and the run instructions are still straightforward.bridges/codex/README.md (1)
1-35: Good cleanup and alignment with bridge docs.The runtime framing, login modes, and
CODEX_HOMEbehavior are documented clearly and match the simplified doc style.docs/msc/com.beeper.mscXXXX-ephemeral.md (1)
3-9: Status note is concise and unambiguous.This clearly communicates that
com.beeper.ephemeralis currently out of scope and points readers to the active streaming model.bridges/openclaw/README.md (1)
1-31: Solid bridge-focused rewrite.The transport/login flow is clearer now, especially the device-pairing note and request ID behavior.
README.md (1)
3-50: Top-level README is much clearer and easier to scan.The bridge table, quick start, and SDK pointers provide a strong entry path without overloading details.
docs/msc/com.beeper.mscXXXX-commands.md (1)
1-34: Compact and practical command-profile spec.The structured-vs-plaintext precedence and built-in command table are clear for implementers and clients.
docs/matrix-ai-matrix-spec-v1.md (4)
1-3: Clear scope and status framing.The intro cleanly sets experimental status and narrows the doc to emitted transport behavior, which matches the PR’s documentation re-scope.
Also applies to: 5-15
16-31: Streaming and persistence semantics are well specified.The canonical
m.room.message+com.beeper.aishape,com.beeper.llmdelta envelope, and finalization authority are concise and internally consistent.Also applies to: 33-70
71-87: Compaction/metadata sections are concise and implementation-oriented.The reduced compaction field list and “Extra keys/Notes” guidance are clear and appropriately scoped for a transport spec.
Also applies to: 91-106
89-89: The relative link to./msc/com.beeper.mscXXXX-commands.mdis valid and the target file exists with the expected content aboutorg.matrix.msc4391.command_description. No issues detected.
| - `./tools/bridges login --env prod` | ||
| - `./tools/bridges auth set-token --token syt_... --env prod` | ||
| - `./tools/bridges whoami` |
There was a problem hiding this comment.
Avoid documenting bearer tokens in command-line arguments.
Passing tokens via --token ... encourages leaking secrets through shell history and command inspection. Please document a safer input path (prompt/env/file) as the primary example.
Suggested doc tweak
- `./tools/bridges login --env prod`
-- `./tools/bridges auth set-token --token syt_... --env prod`
+- `./tools/bridges auth set-token --env prod` # enter token via prompt (preferred)
- `./tools/bridges whoami`🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/bridge-orchestrator.md` around lines 15 - 17, Replace the insecure
example that passes a bearer token on the command line (the `./tools/bridges
auth set-token --token ... --env prod` usage) with a safer pattern: show using
an environment variable (e.g., export BRIDGE_TOKEN=...), a prompt/interactive
flow (e.g., `./tools/bridges auth set-token` which prompts for the token), or
reading from a protected file (e.g., `./tools/bridges auth set-token --file
/path/to/secret`), and make one of those the primary example while keeping a
note about avoiding `--token` on the command line; update the docs lines that
mention `./tools/bridges auth set-token --token` and any help text recommending
`--token` to instead reference `BRIDGE_TOKEN`, interactive prompt, or `--file`.
| - `turn_id` is required | ||
| - `seq` is strictly positive and monotonic per turn | ||
| - `part` is required |
There was a problem hiding this comment.
Clarify seq ordering to avoid ambiguous client behavior.
“Monotonic” can be read as non-decreasing; for stream replay/ordering safety, this should explicitly require strictly increasing sequence numbers.
Suggested wording fix
-- `seq` is strictly positive and monotonic per turn
+- `seq` is strictly increasing per turn (1, 2, 3, ...)📝 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.
| - `turn_id` is required | |
| - `seq` is strictly positive and monotonic per turn | |
| - `part` is required | |
| - `turn_id` is required | |
| - `seq` is strictly increasing per turn (1, 2, 3, ...) | |
| - `part` is required |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/msc/com.beeper.mscXXXX-streaming.md` around lines 61 - 63, The doc
currently says "`seq` is strictly positive and monotonic per turn" which is
ambiguous; update the wording to explicitly require that `seq` is strictly
increasing (i.e., each subsequent `seq` value for the same `turn_id` must be
greater than the previous one), and keep the other constraints (`turn_id` is
required, `part` is required) unchanged so clients know to reject non-increasing
or equal `seq` values.
No description provided.