[PR #1795] [CLOSED] chore: register REA for Claude Code sessions in this checkout #4823

Closed
opened 2026-10-31 00:55:25 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/1795
Author: @trawiarz
Created: 10/11/2026
Status: ❌ Closed

Base: main ← Head: ccr-e28d61a1-65cfs2


📝 Commits (1)

  • c8237cb chore: register REA for Claude Code sessions in this checkout

📊 Changes

6 files changed (+69 additions, -0 deletions)

View changed files

➕ .claude/build-rea.sh (+20 -0)
➕ .claude/hooks/session-start.sh (+17 -0)
➕ .claude/rea-mcp.sh (+7 -0)
➕ .claude/settings.json (+15 -0)
➕ .claude/skills/reverse-engineer-anything (+1 -0)
➕ .mcp.json (+9 -0)

📄 Description

Add project-scoped Claude Code configuration so sessions opened on this repository can use REA without running setup by hand:

  • .mcp.json registers the rea stdio MCP server through .claude/rea-mcp.sh, which builds the checkout first when needed and keeps stdout reserved for the protocol.
  • .claude/settings.json pre-approves that server and runs a cloud-only SessionStart hook that installs locked dependencies with npm ci, runs npm run build:cached, and puts a rea command on PATH.
  • .claude/build-rea.sh serializes the hook and the MCP launcher with flock so a cold start cannot run two installs or builds at once.
  • .claude/skills/reverse-engineer-anything links the authored skill so Claude Code loads REA's workflow instructions.

Validation on Linux (Node 22.22): from an empty checkout the MCP launcher answered initialize in about 18 s and listed 170 tools, both alone and racing the hook; a warm start took about 2 s. analyze-javascript-application on a small Electron fixture recovered its IPC channel and preload bridge. check:fast, format:check, src/config.test.ts and the repository skill discovery check passed. No Ghidra, IDA or Hopper provider was exercised.

Claude-Session: https://claude.ai/code/session_01PoLb7s7LranPeaDeKb3jCJ

Summary

Problem and expected behavior

Change and scope

Contract and boundary impact

  • Semantic owner and earliest changed stage:
  • CLI and MCP/tool-catalog contract:
  • Provider, bridge, target-format, or platform compatibility:
  • Evidence, artifact, provenance, or reconstruction contract:
  • Process execution, authorization, cleanup, or containment impact:
  • 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):

Evidence and regression coverage

  • Tests added or updated:
  • Base reproduction or other evidence:
  • User-visible CLI/MCP output (if applicable):
  • Remaining proof gaps:

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.

Validation performed

  • command — result

Compatibility, safety, and release

  • Breaking changes or migration steps:
  • Real Hopper/Ghidra, browser, or OS coverage:
  • Package or release metadata impact:
  • Security, privacy, process, or containment review:

Review checklist

  • This PR addresses a concrete problem or an agreed enhancement.
  • 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/1795 **Author:** [@trawiarz](https://github.com/trawiarz) **Created:** 10/11/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `ccr-e28d61a1-65cfs2` --- ### 📝 Commits (1) - [`c8237cb`](https://github.com/morluto/rea/commit/c8237cbf295f2e454c358b82e15a5516eef96c09) chore: register REA for Claude Code sessions in this checkout ### 📊 Changes **6 files changed** (+69 additions, -0 deletions) <details> <summary>View changed files</summary> ➕ `.claude/build-rea.sh` (+20 -0) ➕ `.claude/hooks/session-start.sh` (+17 -0) ➕ `.claude/rea-mcp.sh` (+7 -0) ➕ `.claude/settings.json` (+15 -0) ➕ `.claude/skills/reverse-engineer-anything` (+1 -0) ➕ `.mcp.json` (+9 -0) </details> ### 📄 Description Add project-scoped Claude Code configuration so sessions opened on this repository can use REA without running setup by hand: - .mcp.json registers the `rea` stdio MCP server through .claude/rea-mcp.sh, which builds the checkout first when needed and keeps stdout reserved for the protocol. - .claude/settings.json pre-approves that server and runs a cloud-only SessionStart hook that installs locked dependencies with `npm ci`, runs `npm run build:cached`, and puts a `rea` command on PATH. - .claude/build-rea.sh serializes the hook and the MCP launcher with flock so a cold start cannot run two installs or builds at once. - .claude/skills/reverse-engineer-anything links the authored skill so Claude Code loads REA's workflow instructions. Validation on Linux (Node 22.22): from an empty checkout the MCP launcher answered initialize in about 18 s and listed 170 tools, both alone and racing the hook; a warm start took about 2 s. analyze-javascript-application on a small Electron fixture recovered its IPC channel and preload bridge. check:fast, format:check, src/config.test.ts and the repository skill discovery check passed. No Ghidra, IDA or Hopper provider was exercised. Claude-Session: https://claude.ai/code/session_01PoLb7s7LranPeaDeKb3jCJ <!-- PR title: type(optional-scope): imperative outcome The title becomes the squash-merge commit subject and generated changelog entry. --> ## Summary <!-- What user, agent, or maintainer problem does this solve? Link the issue with "Fixes #123" when applicable. Keep the prior behavior, expected contract, and new behavior understandable without private context. --> ## Problem and expected behavior <!-- For fixes, give the smallest trigger and violated invariant. For features, describe the use case and observable outcome. --> ## Change and scope <!-- Explain the chosen approach, why it fits REA's architecture, and what is intentionally not included. --> ## Contract and boundary impact <!-- Complete the applicable lines; use "none" or "not applicable" explicitly. --> - Semantic owner and earliest changed stage: - CLI and MCP/tool-catalog contract: - Provider, bridge, target-format, or platform compatibility: - Evidence, artifact, provenance, or reconstruction contract: - Process execution, authorization, cleanup, or containment impact: - 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): ## Evidence and regression coverage <!-- State whether evidence is executed, source-derived, or proposed. For fixes, explain how the regression would fail on the affected base revision when practical. --> - Tests added or updated: - Base reproduction or other evidence: - User-visible CLI/MCP output (if applicable): - Remaining proof gaps: 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. ## Validation performed <!-- List only commands that actually ran, with observed results. Include the relevant real-provider or platform workflow, or explain why it was unavailable. --> - `command` — result ## Compatibility, safety, and release <!-- Call out breaking changes, migrations, package effects, platform/provider limits, security/privacy/containment implications, and meaningful proof gaps. --> - Breaking changes or migration steps: <!-- For ! / BREAKING CHANGE: show a previously valid call/configuration, its new behavior and migration, and why compatibility/deprecation cannot preserve it. Every release increments minor, including breaking changes; keep breaking markers and migration notes so callers can assess compatibility. See docs/releasing.md. --> - Real Hopper/Ghidra, browser, or OS coverage: - Package or release metadata impact: - Security, privacy, process, or containment review: ## Review checklist - [ ] This PR addresses a concrete problem or an agreed enhancement. - [ ] 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>
bsakaguchi 2026-10-31 00:55:25 +00:00
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#4823
No description provided.