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