Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 32 additions & 0 deletions .github/issue-proposals/repl-multi-api-context-and-routes.md
Original file line number Diff line number Diff line change
@@ -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
Original file line number Diff line number Diff line change
@@ -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 (`<base>/<group>/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 <path>` (existing behavior)
- multi-runner: `.scenario <group> <path>`

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 <group> <path>` 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 <path>` behavior remains unchanged
- [ ] Unit tests cover parsing, error cases, and context binding for both single- and multi-runner modes
Original file line number Diff line number Diff line change
@@ -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 <path>`. With multiple runners, users need completions for:

1. available group keys after `.scenario `
2. scenario paths/functions after `.scenario <group> `

## 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 <group> ` 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 <path>` completions are preserved
- [ ] REPL tests assert completion behavior for both modes and nested scenario paths
Loading