Project Intent: Gambit Deck Format 1.0 (Gambit Core)

Purpose

Implement the Gambit 1.0 deck authoring/runtime contract in @bolt-foundry/gambit-core so downstream surfaces (Simulator UI, Gambit Bot builder, CLI) can rely on a single canonical loader and built-in stdlib asset registry.

@bolt-foundry/gambit-core can load a 1.0 deck entrypoint (PROMPT.md) and parse canonical frontmatter keys, including [[actions]], [[scenarios]], and [[graders]].
[[actions]].path, [[scenarios]].path, and [[graders]].path resolve by linking directly to PROMPT.md files (per the 1.0 spec).
Built-in stdlib namespaces required by the 1.0 spec are implemented: gambit://snippets/*.md, gambit://schemas/**/*.zod.ts, and gambit://decks/*/*/PROMPT.md.
Legacy deck formats and built-in URIs continue to load pre-1.0 with clear deprecation warnings (no silent behavior changes).
Conformance tests exist in packages/gambit-core and gate changes to the loader/resolver behavior.

Do not break existing deck loading behavior before the 1.0 cutover; prefer additive support plus warnings over forced migrations.
Follow the 1.0 spec as the source of truth; do not add new keys/behaviors in gambit-core without updating the spec first.
PROMPT.md frontmatter is the canonical source of deck metadata (label, model params, deck references). The execute code path exists to provide compute behavior, not an alternate metadata surface.
execute and [modelParams] are mutually exclusive: execute decks are compute-only.
Snippet expansion (built-in and local) must match legacy card embed behavior (inline text plus any supported metadata effects such as respond/end hints and schema fragments).
Keep the implementation minimal and composable; avoid large refactors unless they are required to safely support dual-format loading.

Prefer explicit deprecations (warnings + replacement paths) over implicit compatibility magic.
Prefer small, test-backed resolver changes over a broad loader rewrite.
Prefer “resolve by PROMPT.md path” even if it is more verbose than folder references, to keep linking semantics unambiguous.

A spec ambiguity blocks implementation (escalate to Engineering + Product to decide and update the spec).
Supporting 1.0 requires breaking legacy deck behavior pre-1.0.
Downstream adoption (CLI/simulator/bot builder) requires changes that cannot reasonably land independently from the gambit-core implementation.

Run deno test -A packages/gambit-core and confirm tests cover:
- gambit://snippets/*.md embeds resolve and expand as expected.
- gambit://schemas/**/*.zod.ts imports resolve and are usable at runtime.
- [[actions]], [[scenarios]], [[graders]] parse and enforce required fields (including [[actions]].description).
- execute decks load a default-exported defineDeck({ ... run(ctx) ... }) module and PROMPT.md overrides execute-module schema defaults when both are present.
- execute + [modelParams] is rejected (warn pre-1.0, error in 1.0+).
- Legacy namespaces/keys still load and emit deprecation warnings.
Run a minimal simulator/bot-adjacent smoke check (owned by the downstream owners) once the gambit-core changes land, to validate end-to-end loading of a 1.0-style deck.

Activation: When the Gambit Product Command Launch initiative is active and reference/deck-format-1.0.md is the intended canonical spec.
End: When gambit-core supports the 1.0 deck format and the deprecation window is defined/approved (or this intent is superseded).
Revalidation: The 1.0 spec materially changes (keys, namespaces, linking semantics, or built-in asset lists), or downstream consumers discover a blocking mismatch with the implemented contract.

policy/product-command.md
memos/engineering/areas/gambit-core-engineering/INTENT.md
memos/cross-company/projects/gambit-product-command-launch/INTENT.md
memos/cross-company/projects/gambit-product-command-launch/reference/deck-format-1.0.md