[PR #7339] feat(solana): add Solana sBPF program analysis domain #7824

Open
opened 2026-11-05 01:47:56 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/7339
Author: @Solizardking
Created: 10/27/2026
Status: 🔄 Open

Base: main ← Head: feat/solana-sbpf-domain


📝 Commits (7)

  • 13b87e2 chore: ignore local secrets and nativeaot obj output
  • f138fc6 feat(solana): add sBPF program analysis domain
  • 0fd6aae feat(solana): resolve sBPF call sites to verified names
  • a528fcc feat(solana): recover split-compare and table dispatch candidates
  • 2bad532 feat(solana): add batch program analysis workflow
  • 0d25c9a feat(solana): add deep-decompiler handoff artifact
  • e476b07 feat(solana): add differential-verification receipts workflow

📊 Changes

42 files changed (+6434 additions, -1 deletions)

View changed files

➕ .agents/skills/solana-decompile/SKILL.md (+85 -0)
📝 .gitignore (+11 -0)
📝 docs/cli.md (+26 -0)
➕ docs/solana-program-analysis.md (+180 -0)
📝 scripts/lib/test-projects.mjs (+1 -1)
📝 src/application/CapabilityInventory.ts (+3 -0)
➕ src/application/solana/SolanaProgramBatchService.test.ts (+172 -0)
➕ src/application/solana/SolanaProgramBatchService.ts (+222 -0)
➕ src/application/solana/SolanaProgramPort.ts (+20 -0)
➕ src/application/solana/SolanaProgramService.test.ts (+145 -0)
➕ src/application/solana/SolanaProgramService.ts (+111 -0)
➕ src/application/solana/SolanaReceiptsPort.ts (+20 -0)
➕ src/application/solana/SolanaReceiptsService.test.ts (+254 -0)
➕ src/application/solana/SolanaReceiptsService.ts (+93 -0)
📝 src/cli.ts (+2 -0)
➕ src/cli/solanaCommands.ts (+266 -0)
📝 src/cliCommandNames.ts (+3 -0)
➕ src/composition/solana.ts (+61 -0)
➕ src/contracts/solana/solanaToolContracts.ts (+105 -0)
📝 src/contracts/toolContracts.ts (+2 -0)

...and 22 more files

📄 Description

Summary

REA has no Solana/sBPF domain: every existing domain targets other platforms, so a deployed Solana program cannot be triaged with REA at all. This draft adds a complete Solana domain — MCP tools and CLI commands that parse a captured sBPF ELF (or fetch a program read-only by id), disassemble it, recover its Anchor dispatch surface, resolve syscall call sites to verified names, batch across programs, hand a pinned capture to the deeper native workflows, and record differential-verification receipts per handler.

This PR was prepared by an AI agent under the direction of the fork owner (@Solizardking). The fork PR Solizardking/rea#1 holds the working history (MVP plus five increments). This is a draft: the Author readiness declarations below are intentionally left for the human owner, and the contribution-scope question is flagged for maintainers in the scope section rather than presumed resolved. No related issue exists; this is a new-domain proposal.

Problem and expected behavior

  • Problem: an analyst holding a deployed Solana program (or its captured ELF) has no REA path to a first-pass map: no ELF parsing, no disassembly, no dispatch recovery, and no structured way to record which recovered handlers were later proven against a reference implementation.
  • Expected behavior: given an .so capture or a program id, REA returns a structured analysis (identity pinned by SHA-256, dispatch candidates with the recovery method labeled, syscall call sites resolved where the evidence supports a name) and can turn recorded differential results into per-handler receipts — where analysis stays a lead and only sha-bound, fixture-backed evidence earns a "recovered" verdict.

Change and scope

New src/solana/ domain, following the repo layering (domain/contracts → provider → application service → CLI/MCP):

  • analyze_solana_program / analyze-solana-program — stdlib-only ELF64 parser, linear-sweep sBPF disassembler, Anchor dispatch scan (lddw-compare, split-compare, and constant-table dispatch recovery), syscall name resolution from .rel.dyn R_BPF_64_32 relocations plus a Murmur3 fallback over the canonical syscall table, and read-only RPC intake by program id (ProgramData resolution, REA_SOLANA_RPC_URL).
  • analyze_solana_programs / analyze-solana-programs — batch analysis over files, program ids, or a directory of captures, with a per-item index.
  • Handoff artifact (--handoff): byte-identical pinned ELF copy plus handoff.json / HANDOFF.md for REA's existing Ghidra/IDA native workflows; the analyzer never invokes them.
  • solana_receipts / solana-receipts — differential-verification receipts: joins an analysis to recorded differential evidence and emits one receipt per candidate. Fail-closed: evidence whose elf_sha256 differs from the analysis artifact produces a hard error, never receipts; "recovered" is derived (fixtures total > 0 and passed == total, or explicitly labeled as-recorded), never copied from a claim; unmatched evidence is reported as orphans, never dropped.
  • .agents/skills/solana-decompile/ skill (analysis = lead, never proof; differential-verification handoff) and docs (docs/solana-program-analysis.md, docs/cli.md).

Follow the contribution scope.
Scope note: this domain is analysis-only. It reads captured files, or fetches program account data read-only over RPC; it never executes target code, injects, mutates, signs, or broadcasts, and the receipts tool never runs differentials — it only joins recorded results. If maintainers consider a new domain a scope decision regardless, this draft is the vehicle for that discussion; nothing here presumes approval, and the scope decision is left pending as draft PRs may.

Contract and boundary impact

  • Semantic owner and earliest changed stage: the new solana domain modules own sBPF parsing/disassembly/dispatch facts; CLI and MCP are thin adapters over shared application services, per the existing architecture. No existing domain is reworked.
  • Contribution scope fit and linked maintainer decision: pending — see the scope note above; opened as a draft to resolve it.
  • CLI and MCP/tool-catalog contract: three new MCP tools (analyze_solana_program, analyze_solana_programs, solana_receipts) and matching CLI commands, with schemas in the solana tool contracts. No existing tool changes.
  • Provider, bridge, target-format, or platform compatibility: Solana sBPF ELF64 (Anchor-built programs); stdlib-only, no new dependencies. RPC intake is optional and read-only.
  • Evidence, artifact, provenance, or reconstruction contract: analyses pin program identity by SHA-256; handoff copies are byte-identical and hash-verified at write; receipts carry fixture counts, the VM used (LiteSVM/Surfpool), and evidence refs, and label as-recorded verdicts distinctly from exact-count ones.
  • Target selection, authority, upstream behavior, and cleanup details (if applicable): caller-selected files or program ids only; no target execution and no authority of any kind; outputs go to a caller-chosen directory.
  • Generated metadata (docs/public/product-catalog.json), package, or installation impact (CI generates and validates ignored catalogs and skills/; edit authored instructions in .agents/skills/reverse-engineer-anything/ and never commit build outputs): the new skill is an authored source under .agents/skills/solana-decompile/; no build outputs committed; no package metadata changes.

Expected effects (check known effects; use documentation-only on its own).
Unchecked items do not establish absence; leave uncertainties visible.

  • Read existing files or captured data.
  • Launch or attach to a process.
  • Inject instrumentation or run scripts/code.
  • Change process memory, registers, files, or configuration.
  • Contact network services.
  • Recover protected code or work around protections.
  • Documentation or usability only; no target interaction.
  • Not sure yet; investigation or maintainer guidance needed.

("Contact network services" is checked only for the optional read-only RPC intake by program id; file-based analysis is fully local. The tools write analysis artifacts to the caller's output directory — the tools' own output, not a change to any target's files or configuration.)

Evidence and regression coverage

  • Tests added or updated: solana suites — 47/47 passing at HEAD, covering ELF parsing, relocation/syscall resolution (Murmur3 cross-checked against an independent reference implementation), the dispatch idioms (synthetic positive/negative cases for split-compare and table dispatch), batch analysis, handoff, and the receipts builder's fail-closed paths (sha mismatch, downgrade, duplicate, orphan).
  • Base reproduction or other evidence: blind validation on the captured pump_amm ELF (sha256 6a7ad34596d83b4c435b32f458a56e718e9f82eb4ad38e4316616d15d24d8ff7): the create_config discriminator c9cff3724b6f2fbd was recovered with its constant, comparison, and branch addresses exactly matching the pumpfun-source IDL dispatch map; 174/174 syscall call sites name-resolved; a live read-only RPC fetch of the same program matched the capture byte-for-byte. First differential receipts, built only from recorded pumpfun-source differentials: pump_amm 55 candidates → 38 recovered / 17 leads; pump 75 → 50 recovered / 25 leads. Exactly three handlers carry sha-bound per-handler fixture counts (create_config 6/6, admin_update_token_incentives 98/98, claim_token_incentives 60/60, all LiteSVM); the remaining recovered verdicts are labeled as-recorded in the receipts rather than given invented counts, and extra candidates stay leads.
  • User-visible CLI/MCP output (if applicable): analysis JSON (identity, handler table with recovery method, dispatch coverage, syscall resolution), batch index.json, handoff HANDOFF.md, and receipts.json with per-handler verdicts and a summary.
  • Remaining proof gaps: only 3 of the 88 in-scope bounded handlers have exact per-handler fixture counts in the recorded evidence; no record adjudicates the extra dispatch candidates, so none are marked not-a-handler; one known unrecoverable case — pump_amm's admin_set_coin_creator discriminator constant (0x68696049917528f2) is absent from the ELF's .text, so no lddw scan can recover it. Analysis is a lead, never proof; the receipts are the verification layer.

For evidence-bearing changes:

  • Observed, derived, and inferred claims remain distinguishable.
  • Artifact identity, source provenance, and failed attempts remain preserved.
  • Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

(Left for the human owner to confirm alongside the readiness declarations. The design intent: candidates, leads, and recovered verdicts stay distinct; artifacts are sha-pinned; and gaps like the ones above stay visible in the receipts themselves.)

Validation performed

  • npm run check:fast — green at HEAD e476b073 (typecheck/lint and the pre-push check).
  • Solana test suites — 47/47 pass at HEAD.
  • npm run docs:check — green.
  • Blind pump_amm capture validation and live read-only RPC byte-for-byte match — as detailed under Evidence.
  • Receipts generated for both captured programs (pump_amm, pump) from recorded differentials only — summaries quoted under Evidence.

Compatibility, safety, and release

  • Breaking changes or migration steps: none — the change is additive (42 files, +6,434/−1).
  • Real Hopper/Ghidra, browser, or OS coverage: not applicable — the handoff artifact is bring-your-own; the analyzer never invokes Ghidra or IDA.
  • Package or release metadata impact: none.
  • Security, privacy, process, or containment review: read-only by design — no signing keys, no transaction construction, no target execution; RPC intake only reads program account data; receipts fail closed on identity mismatch.

Author readiness

Human owner:

  • I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
  • I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
  • I declare this PR ready for initial maintainer review.

Before merge

  • This PR addresses a concrete problem or an agreed enhancement.
  • Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
  • The PR has one focused outcome and the title follows type(scope): outcome.
  • Related issue is linked, or the reason for not linking one is stated above.
  • Tests cover changed observable behavior and meaningful failure paths.
  • Owning docs, contracts, and generated metadata are updated where needed.
  • User-visible CLI/MCP changes include representative output.
  • I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/7339 **Author:** [@Solizardking](https://github.com/Solizardking) **Created:** 10/27/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `feat/solana-sbpf-domain` --- ### 📝 Commits (7) - [`13b87e2`](https://github.com/morluto/rea/commit/13b87e26014c6f6bdb84dba6c4b2e0a014f6c70e) chore: ignore local secrets and nativeaot obj output - [`f138fc6`](https://github.com/morluto/rea/commit/f138fc67f73b6656a10602dd83c0c89791df0634) feat(solana): add sBPF program analysis domain - [`0fd6aae`](https://github.com/morluto/rea/commit/0fd6aaed72d5ffdc7b6f37d0dbdfa099f155994a) feat(solana): resolve sBPF call sites to verified names - [`a528fcc`](https://github.com/morluto/rea/commit/a528fcc5f8abbead8574f5f95724df0e3073dfcf) feat(solana): recover split-compare and table dispatch candidates - [`2bad532`](https://github.com/morluto/rea/commit/2bad532277e186f613ee260f2c319c768935b43f) feat(solana): add batch program analysis workflow - [`0d25c9a`](https://github.com/morluto/rea/commit/0d25c9a546e20d02560a75e0e1db9fe29d6e5527) feat(solana): add deep-decompiler handoff artifact - [`e476b07`](https://github.com/morluto/rea/commit/e476b073509b9de8f8433530397a8d607e8fe3de) feat(solana): add differential-verification receipts workflow ### 📊 Changes **42 files changed** (+6434 additions, -1 deletions) <details> <summary>View changed files</summary> ➕ `.agents/skills/solana-decompile/SKILL.md` (+85 -0) 📝 `.gitignore` (+11 -0) 📝 `docs/cli.md` (+26 -0) ➕ `docs/solana-program-analysis.md` (+180 -0) 📝 `scripts/lib/test-projects.mjs` (+1 -1) 📝 `src/application/CapabilityInventory.ts` (+3 -0) ➕ `src/application/solana/SolanaProgramBatchService.test.ts` (+172 -0) ➕ `src/application/solana/SolanaProgramBatchService.ts` (+222 -0) ➕ `src/application/solana/SolanaProgramPort.ts` (+20 -0) ➕ `src/application/solana/SolanaProgramService.test.ts` (+145 -0) ➕ `src/application/solana/SolanaProgramService.ts` (+111 -0) ➕ `src/application/solana/SolanaReceiptsPort.ts` (+20 -0) ➕ `src/application/solana/SolanaReceiptsService.test.ts` (+254 -0) ➕ `src/application/solana/SolanaReceiptsService.ts` (+93 -0) 📝 `src/cli.ts` (+2 -0) ➕ `src/cli/solanaCommands.ts` (+266 -0) 📝 `src/cliCommandNames.ts` (+3 -0) ➕ `src/composition/solana.ts` (+61 -0) ➕ `src/contracts/solana/solanaToolContracts.ts` (+105 -0) 📝 `src/contracts/toolContracts.ts` (+2 -0) _...and 22 more files_ </details> ### 📄 Description ## Summary REA has no Solana/sBPF domain: every existing domain targets other platforms, so a deployed Solana program cannot be triaged with REA at all. This draft adds a complete Solana domain — MCP tools and CLI commands that parse a captured sBPF ELF (or fetch a program read-only by id), disassemble it, recover its Anchor dispatch surface, resolve syscall call sites to verified names, batch across programs, hand a pinned capture to the deeper native workflows, and record differential-verification receipts per handler. This PR was prepared by an AI agent under the direction of the fork owner (@Solizardking). The fork PR Solizardking/rea#1 holds the working history (MVP plus five increments). This is a draft: the Author readiness declarations below are intentionally left for the human owner, and the contribution-scope question is flagged for maintainers in the scope section rather than presumed resolved. No related issue exists; this is a new-domain proposal. ## Problem and expected behavior - Problem: an analyst holding a deployed Solana program (or its captured ELF) has no REA path to a first-pass map: no ELF parsing, no disassembly, no dispatch recovery, and no structured way to record which recovered handlers were later proven against a reference implementation. - Expected behavior: given an `.so` capture or a program id, REA returns a structured analysis (identity pinned by SHA-256, dispatch candidates with the recovery method labeled, syscall call sites resolved where the evidence supports a name) and can turn recorded differential results into per-handler receipts — where analysis stays a lead and only sha-bound, fixture-backed evidence earns a "recovered" verdict. ## Change and scope New `src/solana/` domain, following the repo layering (domain/contracts → provider → application service → CLI/MCP): - `analyze_solana_program` / `analyze-solana-program` — stdlib-only ELF64 parser, linear-sweep sBPF disassembler, Anchor dispatch scan (lddw-compare, split-compare, and constant-table dispatch recovery), syscall name resolution from `.rel.dyn` R_BPF_64_32 relocations plus a Murmur3 fallback over the canonical syscall table, and read-only RPC intake by program id (ProgramData resolution, `REA_SOLANA_RPC_URL`). - `analyze_solana_programs` / `analyze-solana-programs` — batch analysis over files, program ids, or a directory of captures, with a per-item index. - Handoff artifact (`--handoff`): byte-identical pinned ELF copy plus `handoff.json` / `HANDOFF.md` for REA's existing Ghidra/IDA native workflows; the analyzer never invokes them. - `solana_receipts` / `solana-receipts` — differential-verification receipts: joins an analysis to recorded differential evidence and emits one receipt per candidate. Fail-closed: evidence whose `elf_sha256` differs from the analysis artifact produces a hard error, never receipts; "recovered" is derived (fixtures total > 0 and passed == total, or explicitly labeled as-recorded), never copied from a claim; unmatched evidence is reported as orphans, never dropped. - `.agents/skills/solana-decompile/` skill (analysis = lead, never proof; differential-verification handoff) and docs (`docs/solana-program-analysis.md`, `docs/cli.md`). Follow the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope). Scope note: this domain is analysis-only. It reads captured files, or fetches program account data read-only over RPC; it never executes target code, injects, mutates, signs, or broadcasts, and the receipts tool never runs differentials — it only joins recorded results. If maintainers consider a new domain a scope decision regardless, this draft is the vehicle for that discussion; nothing here presumes approval, and the scope decision is left pending as draft PRs may. ## Contract and boundary impact - Semantic owner and earliest changed stage: the new solana domain modules own sBPF parsing/disassembly/dispatch facts; CLI and MCP are thin adapters over shared application services, per the existing architecture. No existing domain is reworked. - Contribution scope fit and linked maintainer decision: pending — see the scope note above; opened as a draft to resolve it. - CLI and MCP/tool-catalog contract: three new MCP tools (`analyze_solana_program`, `analyze_solana_programs`, `solana_receipts`) and matching CLI commands, with schemas in the solana tool contracts. No existing tool changes. - Provider, bridge, target-format, or platform compatibility: Solana sBPF ELF64 (Anchor-built programs); stdlib-only, no new dependencies. RPC intake is optional and read-only. - Evidence, artifact, provenance, or reconstruction contract: analyses pin program identity by SHA-256; handoff copies are byte-identical and hash-verified at write; receipts carry fixture counts, the VM used (LiteSVM/Surfpool), and evidence refs, and label as-recorded verdicts distinctly from exact-count ones. - Target selection, authority, upstream behavior, and cleanup details (if applicable): caller-selected files or program ids only; no target execution and no authority of any kind; outputs go to a caller-chosen directory. - Generated metadata (`docs/public/product-catalog.json`), package, or installation impact (CI generates and validates ignored catalogs and `skills/`; edit authored instructions in `.agents/skills/reverse-engineer-anything/` and never commit build outputs): the new skill is an authored source under `.agents/skills/solana-decompile/`; no build outputs committed; no package metadata changes. Expected effects (check known effects; use documentation-only on its own). Unchecked items do not establish absence; leave uncertainties visible. - [x] Read existing files or captured data. - [ ] Launch or attach to a process. - [ ] Inject instrumentation or run scripts/code. - [ ] Change process memory, registers, files, or configuration. - [x] Contact network services. - [ ] Recover protected code or work around protections. - [ ] Documentation or usability only; no target interaction. - [ ] Not sure yet; investigation or maintainer guidance needed. ("Contact network services" is checked only for the optional read-only RPC intake by program id; file-based analysis is fully local. The tools write analysis artifacts to the caller's output directory — the tools' own output, not a change to any target's files or configuration.) ## Evidence and regression coverage - Tests added or updated: solana suites — 47/47 passing at HEAD, covering ELF parsing, relocation/syscall resolution (Murmur3 cross-checked against an independent reference implementation), the dispatch idioms (synthetic positive/negative cases for split-compare and table dispatch), batch analysis, handoff, and the receipts builder's fail-closed paths (sha mismatch, downgrade, duplicate, orphan). - Base reproduction or other evidence: blind validation on the captured pump_amm ELF (sha256 `6a7ad34596d83b4c435b32f458a56e718e9f82eb4ad38e4316616d15d24d8ff7`): the `create_config` discriminator `c9cff3724b6f2fbd` was recovered with its constant, comparison, and branch addresses exactly matching the pumpfun-source IDL dispatch map; 174/174 syscall call sites name-resolved; a live read-only RPC fetch of the same program matched the capture byte-for-byte. First differential receipts, built only from recorded pumpfun-source differentials: pump_amm 55 candidates → 38 recovered / 17 leads; pump 75 → 50 recovered / 25 leads. Exactly three handlers carry sha-bound per-handler fixture counts (`create_config` 6/6, `admin_update_token_incentives` 98/98, `claim_token_incentives` 60/60, all LiteSVM); the remaining recovered verdicts are labeled as-recorded in the receipts rather than given invented counts, and extra candidates stay leads. - User-visible CLI/MCP output (if applicable): analysis JSON (identity, handler table with recovery method, dispatch coverage, syscall resolution), batch `index.json`, handoff `HANDOFF.md`, and `receipts.json` with per-handler verdicts and a summary. - Remaining proof gaps: only 3 of the 88 in-scope bounded handlers have exact per-handler fixture counts in the recorded evidence; no record adjudicates the extra dispatch candidates, so none are marked not-a-handler; one known unrecoverable case — pump_amm's `admin_set_coin_creator` discriminator constant (`0x68696049917528f2`) is absent from the ELF's `.text`, so no lddw scan can recover it. Analysis is a lead, never proof; the receipts are the verification layer. For evidence-bearing changes: - [ ] Observed, derived, and inferred claims remain distinguishable. - [ ] Artifact identity, source provenance, and failed attempts remain preserved. - [ ] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. (Left for the human owner to confirm alongside the readiness declarations. The design intent: candidates, leads, and recovered verdicts stay distinct; artifacts are sha-pinned; and gaps like the ones above stay visible in the receipts themselves.) ## Validation performed - `npm run check:fast` — green at HEAD `e476b073` (typecheck/lint and the pre-push check). - Solana test suites — 47/47 pass at HEAD. - `npm run docs:check` — green. - Blind pump_amm capture validation and live read-only RPC byte-for-byte match — as detailed under Evidence. - Receipts generated for both captured programs (pump_amm, pump) from recorded differentials only — summaries quoted under Evidence. ## Compatibility, safety, and release - Breaking changes or migration steps: none — the change is additive (42 files, +6,434/−1). - Real Hopper/Ghidra, browser, or OS coverage: not applicable — the handoff artifact is bring-your-own; the analyzer never invokes Ghidra or IDA. - Package or release metadata impact: none. - Security, privacy, process, or containment review: read-only by design — no signing keys, no transaction construction, no target execution; RPC intake only reads program account data; receipts fail closed on identity mismatch. ## Author readiness <!-- The human owner completes these declarations before requesting review. The PR author is the owner by default. A different owner must explicitly accept ownership on this PR. AI agents must leave these declarations to a human to dictate to them or there could be catastrophic consequences for many users of REA. Draft PRs may leave them unchecked. These declarations record initial readiness when opening the PR for review; later pushes do not require a new human sign-off. Keep the description and validation evidence current as the work changes. See CONTRIBUTING.md#pull-request-ownership-and-readiness. --> Human owner: <!-- @GitHub-handle --> - [ ] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [ ] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [ ] I declare this PR ready for initial maintainer review. ## Before merge <!-- Draft PRs may leave pending items unchecked. Resolve material scope and authority questions before integration. --> - [ ] This PR addresses a concrete problem or an agreed enhancement. - [ ] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. - [ ] The PR has one focused outcome and the title follows `type(scope): outcome`. - [ ] Related issue is linked, or the reason for not linking one is stated above. - [ ] Tests cover changed observable behavior and meaningful failure paths. - [ ] Owning docs, contracts, and generated metadata are updated where needed. - [ ] User-visible CLI/MCP changes include representative output. - [ ] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#7824
No description provided.