Skip to content

update docs#74

Open
batuhan wants to merge 2 commits intomainfrom
batuhan/docs
Open

update docs#74
batuhan wants to merge 2 commits intomainfrom
batuhan/docs

Conversation

@batuhan
Copy link
Member

@batuhan batuhan commented Mar 22, 2026

No description provided.

@coderabbitai
Copy link

coderabbitai bot commented Mar 22, 2026

📝 Walkthrough

Summary by CodeRabbit

Documentation

  • Documentation
    • Reorganized project README with clarified bridge layer terminology and streamlined setup guidance
    • Simplified bridge-specific documentation (Codex, OpenCode, OpenClaw) with focused configuration instructions
    • Updated CLI command reference with refined syntax and examples
    • Consolidated technical specifications for Matrix AI transport and command profiles to emphasize implemented features

Walkthrough

This 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

Cohort / File(s) Summary
Root README
README.md
Reframed AgentRemote as a bridge layer, removed extensive setup/SDK content, simplified quick-start commands, introduced smaller "Useful commands" section, and added SDK documentation pointing to sdk/ and core types.
Bridge Documentation
bridges/codex/README.md, bridges/openclaw/README.md, bridges/opencode/README.md
Renamed bridges and inverted directionality descriptions to show Beeper connecting to runtimes rather than runtimes connecting to Beeper. Simplified feature lists, consolidated authentication sections, removed "best fit" and "notes" sections.
CLI Documentation
docs/bridge-orchestrator.md
Retitled from "Bridge Orchestrator" to "AgentRemote CLI," rescoped to describe ./tools/bridges as local entrypoint for agentremote. Streamlined command listings, added quick examples, and updated instance data path documentation.
Core Specification
docs/matrix-ai-matrix-spec-v1.md
Drastically condensed from long-form detailed requirements to concise description of actual code emission. Removed extensive streaming/approval/delta envelope details, replaced with simplified payload documentation and state event references.
Command Profile Specification
docs/msc/com.beeper.mscXXXX-commands.md
Rewritten from detailed MSC4391 specification to brief overview. Removed structured invocation rules, security considerations, and fallback precedence; replaced with simple table of built-in commands and generic plain-text fallback note.
Ephemeral Events Specification
docs/msc/com.beeper.mscXXXX-ephemeral.md
Removed full specification for com.beeper.ephemeral custom events. Replaced with brief status note stating no bridge implements the feature and pointing to message-anchored streaming instead.
Streaming Specification
docs/msc/com.beeper.mscXXXX-streaming.md
Condensed from end-to-end protocol description to current model specification. Removed subscription/encryption details, added minimal delta envelope schema and compaction behavior, and noted wire protocol as out of scope.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

🚥 Pre-merge checks | ✅ 1 | ❌ 2

❌ Failed checks (2 inconclusive)

Check name Status Explanation Resolution
Title check ❓ Inconclusive The title 'update docs' is vague and generic, providing no meaningful information about which documentation was updated or what the changes accomplish. Use a more descriptive title that indicates the main scope of documentation changes, such as 'Redefine AgentRemote as bridge layer and update bridge/spec documentation' or similar.
Description check ❓ Inconclusive No pull request description was provided by the author, making it impossible to assess whether the intent relates to the changeset. Add a pull request description explaining the purpose of the documentation updates, the main changes, and why they were necessary.
✅ Passed checks (1 passed)
Check name Status Explanation
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch batuhan/docs

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

📥 Commits

Reviewing files that changed from the base of the PR and between 14bc6a6 and d80e9f8.

📒 Files selected for processing (9)
  • README.md
  • bridges/codex/README.md
  • bridges/openclaw/README.md
  • bridges/opencode/README.md
  • docs/bridge-orchestrator.md
  • docs/matrix-ai-matrix-spec-v1.md
  • docs/msc/com.beeper.mscXXXX-commands.md
  • docs/msc/com.beeper.mscXXXX-ephemeral.md
  • docs/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 (remote vs managed) 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_HOME behavior 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.ephemeral is 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.ai shape, com.beeper.llm delta 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.md is valid and the target file exists with the expected content about org.matrix.msc4391.command_description. No issues detected.

Comment on lines +15 to +17
- `./tools/bridges login --env prod`
- `./tools/bridges auth set-token --token syt_... --env prod`
- `./tools/bridges whoami`
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

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`.

Comment on lines +61 to +63
- `turn_id` is required
- `seq` is strictly positive and monotonic per turn
- `part` is required
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

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.

Suggested change
- `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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant