Base implementation of EXT-13 + EXT-15 (P0 pair for RDM G1; proposal modules/documents/docs/proposals/2026-10-09-ext-g1-b1-b3-exec-backend.md):
EXT-13 in-run shared retrieval: runmgr.Manager.SetSharedKnowledgeAllow routes runCtx.Retrieve (the knowledge_search tool and @knowledge injection) through RetrieveShared when a predicate is registered — the run's agent now sees adapter-authorized shared knowledge on the same terms as the HTTP search face. hostcaps.search (in-proc Host.KnowledgeSearch) consults the same EXT-8 slot. Wired in the composition root from the shared authzSlot (first-registrant, late registration effective).
EXT-15 shared project list + conversation creation: GET /api/projects appends adapter-authorized shared projects via projectView (shared: true, deduped, owner items unchanged); POST /api/projects/{id}/conversations falls back to CreateConversationInProject (existence check only, conversation still owned by the creator) when the own-project path misses and the adapter authorizes. New store methods ListAllProjects (candidates only — callers must filter through the adapter) and CreateConversationInProject.
Why
RDM G1 sequence-4 (multi-user sharing) hard-blocked on both: the member agent's knowledge gap contradicts the user supplement (§2树1图), and SR-G10 requires members to see and work in shared projects.
Tests
Red → green: TestRunContextRetrieveShared, TestInprocHostKnowledgeSearchShared, TestSharedProjectListAndConversation (including revocation → immediate 404/zero hits and no-adapter = unchanged). go test ./... 32/32 packages ok. CI on this PR is the GATE.
## Summary
Base implementation of **EXT-13 + EXT-15** (P0 pair for RDM G1; proposal `modules/documents/docs/proposals/2026-10-09-ext-g1-b1-b3-exec-backend.md`):
- **EXT-13 in-run shared retrieval**: `runmgr.Manager.SetSharedKnowledgeAllow` routes `runCtx.Retrieve` (the `knowledge_search` tool and `@knowledge` injection) through `RetrieveShared` when a predicate is registered — the run's agent now sees adapter-authorized shared knowledge on the same terms as the HTTP search face. `hostcaps.search` (in-proc `Host.KnowledgeSearch`) consults the same EXT-8 slot. Wired in the composition root from the shared `authzSlot` (first-registrant, late registration effective).
- **EXT-15 shared project list + conversation creation**: `GET /api/projects` appends adapter-authorized shared projects via `projectView` (`shared: true`, deduped, owner items unchanged); `POST /api/projects/{id}/conversations` falls back to `CreateConversationInProject` (existence check only, conversation still owned by the creator) when the own-project path misses and the adapter authorizes. New store methods `ListAllProjects` (candidates only — callers must filter through the adapter) and `CreateConversationInProject`.
## Why
RDM G1 sequence-4 (multi-user sharing) hard-blocked on both: the member agent's knowledge gap contradicts the user supplement (§2树1图), and SR-G10 requires members to see and work in shared projects.
## Tests
Red → green: `TestRunContextRetrieveShared`, `TestInprocHostKnowledgeSearchShared`, `TestSharedProjectListAndConversation` (including revocation → immediate 404/zero hits and no-adapter = unchanged). `go test ./...` 32/32 packages ok. CI on this PR is the GATE.
## Compat
No `pkg/extension` surface change (SurfaceVersion unchanged); adapter absent = byte-for-byte previous behavior.
Why: A member's agent cannot see published project knowledge inside a run
(runCtx.Retrieve and hostcaps.search are owner-only), and members can
neither see shared projects nor open conversations in them - both are P0
prerequisites for RDM G1 (EXT-13/EXT-15, proposal
2026-10-09-ext-g1-b1-b3-exec-backend).
Evidence: Red tests first - TestRunContextRetrieveShared (undefined
SetSharedKnowledgeAllow), TestInprocHostKnowledgeSearchShared (0 shared
hits), TestSharedProjectListAndConversation (empty list) all failed before
and pass after; go test ./... 32/32 packages ok.
Impact: runmgr gains SetSharedKnowledgeAllow and routes Retrieve through
RetrieveShared when the predicate is registered (nil = unchanged); hostcaps
search consults the same EXT-8 slot; GET /api/projects appends
adapter-authorized shared projects (projectView with shared flag, deduped);
POST /api/projects/{id}/conversations falls back to
CreateConversationInProject when the own-project path misses and the
adapter authorizes; store gains ListAllProjects (candidates only, callers
must filter through the adapter) and CreateConversationInProject.
Revocation takes effect immediately on both paths; absence of an adapter
is byte-for-byte the previous behavior. No pkg/extension surface change.
Refs: docs/proposals/2026-10-09-ext-g1-b1-b3-exec-backend.md (EXT-13, EXT-15)
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
Base implementation of EXT-13 + EXT-15 (P0 pair for RDM G1; proposal
modules/documents/docs/proposals/2026-10-09-ext-g1-b1-b3-exec-backend.md):runmgr.Manager.SetSharedKnowledgeAllowroutesrunCtx.Retrieve(theknowledge_searchtool and@knowledgeinjection) throughRetrieveSharedwhen a predicate is registered — the run's agent now sees adapter-authorized shared knowledge on the same terms as the HTTP search face.hostcaps.search(in-procHost.KnowledgeSearch) consults the same EXT-8 slot. Wired in the composition root from the sharedauthzSlot(first-registrant, late registration effective).GET /api/projectsappends adapter-authorized shared projects viaprojectView(shared: true, deduped, owner items unchanged);POST /api/projects/{id}/conversationsfalls back toCreateConversationInProject(existence check only, conversation still owned by the creator) when the own-project path misses and the adapter authorizes. New store methodsListAllProjects(candidates only — callers must filter through the adapter) andCreateConversationInProject.Why
RDM G1 sequence-4 (multi-user sharing) hard-blocked on both: the member agent's knowledge gap contradicts the user supplement (§2树1图), and SR-G10 requires members to see and work in shared projects.
Tests
Red → green:
TestRunContextRetrieveShared,TestInprocHostKnowledgeSearchShared,TestSharedProjectListAndConversation(including revocation → immediate 404/zero hits and no-adapter = unchanged).go test ./...32/32 packages ok. CI on this PR is the GATE.Compat
No
pkg/extensionsurface change (SurfaceVersion unchanged); adapter absent = byte-for-byte previous behavior.Why: A member's agent cannot see published project knowledge inside a run (runCtx.Retrieve and hostcaps.search are owner-only), and members can neither see shared projects nor open conversations in them - both are P0 prerequisites for RDM G1 (EXT-13/EXT-15, proposal 2026-10-09-ext-g1-b1-b3-exec-backend). Evidence: Red tests first - TestRunContextRetrieveShared (undefined SetSharedKnowledgeAllow), TestInprocHostKnowledgeSearchShared (0 shared hits), TestSharedProjectListAndConversation (empty list) all failed before and pass after; go test ./... 32/32 packages ok. Impact: runmgr gains SetSharedKnowledgeAllow and routes Retrieve through RetrieveShared when the predicate is registered (nil = unchanged); hostcaps search consults the same EXT-8 slot; GET /api/projects appends adapter-authorized shared projects (projectView with shared flag, deduped); POST /api/projects/{id}/conversations falls back to CreateConversationInProject when the own-project path misses and the adapter authorizes; store gains ListAllProjects (candidates only, callers must filter through the adapter) and CreateConversationInProject. Revocation takes effect immediately on both paths; absence of an adapter is byte-for-byte the previous behavior. No pkg/extension surface change. Refs: docs/proposals/2026-10-09-ext-g1-b1-b3-exec-backend.md (EXT-13, EXT-15)