G1 extension application package (plan V1.1 §5.3, owner Q1–Q8): docs/proposals/2026-10-09-ext-g1-b1-b3-exec-backend.md registering EXT-13…EXT-16 per the compat-policy template:
EXT-13 (B-1, P0) in-run shared retrieval — runCtx.Retrieve (runmgr.go:726-736) and hostcaps.search (hostcaps.go:64-66) are owner-only today, so a member's agent cannot see published project knowledge inside a run; wire the EXT-8 authorizer through the same RetrieveShared implementation the HTTP face already uses.
EXT-15 (B-3, P0) shared project list + conversation creation — listProjects (server.go:438-441) and CreateConversation's ownership check (store/projects.go:124-130) consult the same authorizer; unblocks SR-G10 (members see and can work in shared projects).
EXT-14 (B-2, P1) commands-as-tools (Q4 option A) — optional exposeAsTool on command specs; model calls dispatch through the command bus (Entrance="agent", same audit envelope and HITL confirmation), extending the four same-source entries with a fifth.
EXT-16 (B-5②, P1) exec backend seam — abstract the interpreter's process launch into an ExecBackend (direct | sandbox); sandbox = bwrap with read-only root, workspace-only mounts, no network, cgroup limits; DisableExecTools stays as the final override (Q2 phase 2, G2-8 prototype).
Why
RDM G1 sequence-4 (multi-user sharing) and G2 (V0.1 end-to-end) are hard-blocked on these; the member-agent knowledge gap directly contradicts the user's supplement (§2树1图: all agents must see project-level shared info).
Tests
Docs only. Code citations verified at Dev main (paths/lines in the proposal).
Refs
RDM docs/proposals/2026-10-09-V22-review-and-implementation-plan.md §3.3/§3.4/§5.3; C1–C7 package (EXT-6…12) stays on its own track.
## Summary
G1 extension application package (plan V1.1 §5.3, owner Q1–Q8): `docs/proposals/2026-10-09-ext-g1-b1-b3-exec-backend.md` registering **EXT-13…EXT-16** per the compat-policy template:
- **EXT-13 (B-1, P0)** in-run shared retrieval — `runCtx.Retrieve` (runmgr.go:726-736) and `hostcaps.search` (hostcaps.go:64-66) are owner-only today, so a member's agent cannot see published project knowledge inside a run; wire the EXT-8 authorizer through the same `RetrieveShared` implementation the HTTP face already uses.
- **EXT-15 (B-3, P0)** shared project list + conversation creation — `listProjects` (server.go:438-441) and `CreateConversation`'s ownership check (store/projects.go:124-130) consult the same authorizer; unblocks SR-G10 (members see and can work in shared projects).
- **EXT-14 (B-2, P1)** commands-as-tools (Q4 option A) — optional `exposeAsTool` on command specs; model calls dispatch through the command bus (Entrance="agent", same audit envelope and HITL confirmation), extending the four same-source entries with a fifth.
- **EXT-16 (B-5②, P1)** exec backend seam — abstract the interpreter's process launch into an ExecBackend (direct | sandbox); sandbox = bwrap with read-only root, workspace-only mounts, no network, cgroup limits; `DisableExecTools` stays as the final override (Q2 phase 2, G2-8 prototype).
## Why
RDM G1 sequence-4 (multi-user sharing) and G2 (V0.1 end-to-end) are hard-blocked on these; the member-agent knowledge gap directly contradicts the user's supplement (§2树1图: all agents must see project-level shared info).
## Tests
Docs only. Code citations verified at Dev main (paths/lines in the proposal).
## Refs
RDM `docs/proposals/2026-10-09-V22-review-and-implementation-plan.md` §3.3/§3.4/§5.3; C1–C7 package (EXT-6…12) stays on its own track.
Why: RDM G1/G2 are blocked on four base capabilities - the member agent
cannot see published project knowledge inside a run, plugin commands are
unreachable as tools, members cannot see or open conversations in shared
projects, and the isolated exec tier needs a backend seam.
Evidence: SELF - code citations verified at Dev main (runmgr.go:726-736
owner-only Retrieve; hostcaps.go:64-66 owner-only search; server.go:438-441
owner-only listProjects; store/projects.go:124-130 owner-scoped conversation
creation); bwrap availability tested on this host (2026-10-09).
Impact: Docs only. New proposal docs/proposals/2026-10-09-ext-g1-b1-b3-exec-backend.md
registering EXT-13..EXT-16 per the compat-policy template; no code change.
Refs: RDM plan V1.1 sections 3.3/3.4/5.3; owner Q1-Q8 (Q4=option A, Q2)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
G1 extension application package (plan V1.1 §5.3, owner Q1–Q8):
docs/proposals/2026-10-09-ext-g1-b1-b3-exec-backend.mdregistering EXT-13…EXT-16 per the compat-policy template:runCtx.Retrieve(runmgr.go:726-736) andhostcaps.search(hostcaps.go:64-66) are owner-only today, so a member's agent cannot see published project knowledge inside a run; wire the EXT-8 authorizer through the sameRetrieveSharedimplementation the HTTP face already uses.listProjects(server.go:438-441) andCreateConversation's ownership check (store/projects.go:124-130) consult the same authorizer; unblocks SR-G10 (members see and can work in shared projects).exposeAsToolon command specs; model calls dispatch through the command bus (Entrance="agent", same audit envelope and HITL confirmation), extending the four same-source entries with a fifth.DisableExecToolsstays as the final override (Q2 phase 2, G2-8 prototype).Why
RDM G1 sequence-4 (multi-user sharing) and G2 (V0.1 end-to-end) are hard-blocked on these; the member-agent knowledge gap directly contradicts the user's supplement (§2树1图: all agents must see project-level shared info).
Tests
Docs only. Code citations verified at Dev main (paths/lines in the proposal).
Refs
RDM
docs/proposals/2026-10-09-V22-review-and-implementation-plan.md§3.3/§3.4/§5.3; C1–C7 package (EXT-6…12) stays on its own track.9707d6dc01to1f8ad3b99b