diff --git a/.github/issue-proposals/repl-multi-api-context-and-routes.md b/.github/issue-proposals/repl-multi-api-context-and-routes.md
new file mode 100644
index 000000000..e9fb9e5d1
--- /dev/null
+++ b/.github/issue-proposals/repl-multi-api-context-and-routes.md
@@ -0,0 +1,32 @@
+---
+title: "repl: expose multi-API context/routes by group name"
+parentIssue: 1893
+labels:
+ - enhancement
+ - repl
+assignees: []
+milestone:
+---
+
+When Counterfact runs multiple `ApiRunner`s, the REPL currently uses only the first runner. This proposal updates REPL bootstrapping so all runners are available and scenario/route helpers can target each API by group key.
+
+## Context
+
+Multi-spec projects need to inspect and mutate state across APIs (for example `billing` and `inventory`) in one REPL session. Today, only the first runner is wired into `context`, `loadContext`, and `route`, so users cannot reliably operate on non-primary APIs.
+
+## Proposed change
+
+Update app/repl wiring so REPL receives all active runners and builds grouped affordances:
+
+- `context` becomes a map keyed by API group (`context.billing`, `context.inventory`, ...)
+- `routes` becomes a grouped map using the same keys
+- helper wiring is updated so grouped APIs can be addressed consistently
+- single-runner mode keeps current unqualified behavior for backwards compatibility
+
+## Acceptance criteria
+
+- [ ] REPL startup path passes all configured runners (not only the first) into REPL initialization
+- [ ] In multi-runner mode, `context` and `routes` are keyed by each runner's group name
+- [ ] Behavior for a single runner remains unchanged (`context` remains the root context object)
+- [ ] Group-key collisions or missing group names are handled deterministically and documented in code/tests
+- [ ] Unit tests cover single-runner and multi-runner REPL context wiring
diff --git a/.github/issue-proposals/repl-scenario-command-with-group-qualifier.md b/.github/issue-proposals/repl-scenario-command-with-group-qualifier.md
new file mode 100644
index 000000000..f606afeff
--- /dev/null
+++ b/.github/issue-proposals/repl-scenario-command-with-group-qualifier.md
@@ -0,0 +1,32 @@
+---
+title: "repl: add group-qualified .scenario command for multi-API"
+parentIssue: 1893
+labels:
+ - enhancement
+ - repl
+assignees: []
+milestone:
+---
+
+Extend `.scenario` so multi-API sessions can choose which API runner's scenario registry and context are used.
+
+## Context
+
+Scenario scripts are loaded per runner (`//scenarios`). In multi-runner mode, `.scenario` needs an API qualifier to avoid ambiguity and to execute against the intended context/route helpers.
+
+## Proposed change
+
+Add dual command syntax:
+
+- single-runner: `.scenario ` (existing behavior)
+- multi-runner: `.scenario `
+
+The command should resolve the selected group, load that group's scenario module, and pass the group's `context`, `loadContext`, `route`, and `routes` into the scenario function.
+
+## Acceptance criteria
+
+- [ ] `.scenario ` executes scenarios for the selected group in multi-runner mode
+- [ ] Unknown group names produce a clear error message with available group keys
+- [ ] Invalid or missing arguments print mode-appropriate usage help
+- [ ] Single-runner `.scenario ` behavior remains unchanged
+- [ ] Unit tests cover parsing, error cases, and context binding for both single- and multi-runner modes
diff --git a/.github/issue-proposals/repl-tab-completion-for-multi-api-scenario.md b/.github/issue-proposals/repl-tab-completion-for-multi-api-scenario.md
new file mode 100644
index 000000000..cdaec1c3f
--- /dev/null
+++ b/.github/issue-proposals/repl-tab-completion-for-multi-api-scenario.md
@@ -0,0 +1,30 @@
+---
+title: "repl: update tab completion for group-qualified .scenario"
+parentIssue: 1893
+labels:
+ - enhancement
+ - repl
+assignees: []
+milestone:
+---
+
+Update REPL tab completion so `.scenario` completions reflect the new multi-API qualifier syntax while preserving the current single-API experience.
+
+## Context
+
+Current completion assumes `.scenario `. With multiple runners, users need completions for:
+
+1. available group keys after `.scenario `
+2. scenario paths/functions after `.scenario `
+
+## Proposed change
+
+Refactor the `.scenario` completer to operate in two stages for multi-runner mode and keep existing path/function completion for single-runner mode.
+
+## Acceptance criteria
+
+- [ ] In multi-runner mode, typing `.scenario ` offers available group keys
+- [ ] In multi-runner mode, typing `.scenario ` offers scenario path/function completions scoped to that group
+- [ ] Invalid groups do not crash completion and fall back gracefully
+- [ ] In single-runner mode, existing `.scenario ` completions are preserved
+- [ ] REPL tests assert completion behavior for both modes and nested scenario paths