Skip to content

[codex] prototype default global scope#183

Open
briancavalier wants to merge 7 commits into
mainfrom
codex/default-global-scope-prototype
Open

[codex] prototype default global scope#183
briancavalier wants to merge 7 commits into
mainfrom
codex/default-global-scope-prototype

Conversation

@briancavalier

Copy link
Copy Markdown
Owner

Summary

Prototype a default global scope as a real exported scope value rather than ambient runtime machinery.

Changes

  • Add GlobalScope and export it from the public API, including the ./GlobalScope package subpath.
  • Add default global-scope overloads for scope(), abort(), orReturn(value), and returnFrom(value) while preserving explicit scoped forms.
  • Adjust Yielding phantom output typing so multiple protocols on the same runtime scope extract outputs as a union and inputs as an intersection.
  • Add focused tests for default scope behavior, explicit scope isolation, and YieldFrom type composition.

Validation

  • pnpm test
  • pnpm typecheck
  • pnpm build
  • pnpm lint

@briancavalier briancavalier marked this pull request as ready for review May 18, 2026 23:40

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 626a37a5e8

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread src/YieldFrom.ts Outdated
Comment on lines +64 to +68
(_: infer A): void
(_: infer B): void
(_: infer C): void
(_: infer D): void
} ? A | B | C | D

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Remove four-signature cap in YieldOutput union extraction

YieldOutputUnion only infers up to four callable signatures, so scopes composed from five or more Yielding<...> protocols silently lose at least one output variant at the type level. In practice this makes yieldFrom(scope, value) reject valid payloads (or mis-type handlers) once a scope carries >4 protocols, even though runtime behavior still supports them. This regression is introduced by the fixed-arity conditional and can be reproduced with a string & Yielding<A> & ... & Yielding<E> scope where one member drops from YieldOutput.

Useful? React with 👍 / 👎.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 290535c11c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread src/YieldFrom.ts Outdated
*/
export const collectFrom = <const Scope extends string & Yielding<unknown, void>>(scope: Scope) =>
export const collectFrom = <const Scope extends string & AnyYielding>(
scope: YieldInput<Scope> extends void ? Scope : never

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Reject bidirectional scopes in collectFrom

collectFrom is now gated by YieldInput<Scope> extends void, but YieldInput for multi-protocol scopes is computed as an intersection, so a mixed scope like Yielding<..., void> & Yielding<..., {reply: ...}> collapses to never and still passes this check (never extends void). In that case collectFrom will handle YieldFrom requests that actually require a response and return undefined at runtime, violating the typed request/response contract and causing downstream failures when the yielded result is used.

Useful? React with 👍 / 👎.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: efce671ed2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread src/YieldFrom.ts
Comment on lines +45 to 46
export type YieldValue<E, Scope extends string & AnyYielding> =
E extends YieldFrom<Scope> ? YieldOutput<Scope> : never

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Match YieldFrom by exact protocol set, not subtype scope

Using E extends YieldFrom<Scope> here lets a scope with extra Yielding<...> protocols be treated as the same scope because those branded types are structural supersets. In practice, collectFrom(oneProtocolScope) will also intercept YieldFrom effects emitted with a multi-protocol scope that shares the same runtime scope string, but the returned tuple is typed as if only YieldOutput<oneProtocolScope> can appear. That drops valid output variants from types and can break downstream exhaustive handling when multi-protocol scopes are composed on one runtime scope.

Useful? React with 👍 / 👎.

@briancavalier briancavalier added the experiment An experiment to explore an idea. May never be merged label May 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

experiment An experiment to explore an idea. May never be merged

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant