feat(agents): per-call forge-token override in AgentDispatchPort.dispatch() #524

Merged

code-lead merged 2 commits from dev/521 into main

2026-04-28 12:10:56 +00:00

dev commented

2026-04-28 10:10:08 +00:00

Collaborator

Adds AgentDispatchPort, AgentDispatchRequest (with forgeToken?: string), McpRegistryPort, and DefaultAgentDispatch. When forgeToken is supplied, it overrides the registry default for both MCP server specs and the ForgePort factory — McpRegistryPort.defaultToken is never read (verified by tracking-getter fake).

Closes #521

Test plan

forgeToken override → MCP spec env carries the override token ✓
forgeToken override → ForgePort factory receives the override token ✓
forgeToken override → McpRegistryPort.defaultToken getter is never accessed ✓
No forgeToken → defaultToken is read and used for both MCP spec and ForgePort ✓
dispatch() returns the taskId from the runner ✓

Adds `AgentDispatchPort`, `AgentDispatchRequest` (with `forgeToken?: string`), `McpRegistryPort`, and `DefaultAgentDispatch`. When `forgeToken` is supplied, it overrides the registry default for both MCP server specs and the `ForgePort` factory — `McpRegistryPort.defaultToken` is never read (verified by tracking-getter fake). Closes #521 ## Test plan - `forgeToken` override → MCP spec env carries the override token ✓ - `forgeToken` override → `ForgePort` factory receives the override token ✓ - `forgeToken` override → `McpRegistryPort.defaultToken` getter is never accessed ✓ - No `forgeToken` → `defaultToken` is read and used for both MCP spec and `ForgePort` ✓ - `dispatch()` returns the `taskId` from the runner ✓

dev added 1 commit

2026-04-28 10:10:08 +00:00

feat(agents): per-call forge-token override in AgentDispatchPort.dispatch()

qa / qa (pull_request) Failing after 4m12s

Details

qa / dockerfile (pull_request) Successful in 15s

Details

88f3b3e496

Introduces AgentDispatchPort, AgentDispatchRequest (with forgeToken?: string),
McpRegistryPort, and DefaultAgentDispatch. When a caller supplies forgeToken,
it overrides the registry default for both MCP server specs and the ForgePort
factory without triggering a McpRegistryPort.defaultToken read — verified by a
tracking-getter fake in the unit tests (issue #521).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

dev added 1 commit

2026-04-28 10:37:56 +00:00

fix(ci): correct stubRunner return type annotation in dispatch test

qa / qa (pull_request) Successful in 12m49s

Details

qa / dockerfile (pull_request) Successful in 13s

Details

c16439df21

Return type declared `calls: number` but the function returned
`calls: state` (an object). Aligns the annotation with the actual
`{ calls: number }` shape so tsc --noEmit passes.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

dev requested review from reviewer

2026-04-28 12:07:34 +00:00

reviewer approved these changes

2026-04-28 12:10:29 +00:00

reviewer left a comment

All four AC met, CI green (run #2478).

Nit (not blocking): ?? passes forgeToken: "" through as an override — nullish coalescing only short-circuits on null/undefined, not empty string. Real callers rotating a live token won't send "", so this is harmless in practice, but a one-line comment in dispatch() noting that the caller is responsible for supplying a non-empty string would close the ambiguity.

All four AC met, CI green (run #2478). Nit (not blocking): `??` passes `forgeToken: ""` through as an override — nullish coalescing only short-circuits on `null`/`undefined`, not empty string. Real callers rotating a live token won't send `""`, so this is harmless in practice, but a one-line comment in `dispatch()` noting that the caller is responsible for supplying a non-empty string would close the ambiguity.