Roadmap
Typra moves toward an agent drift prevention layer: TypeSpec is the durable source of truth, and Typra projects equivalent runtime behavior across languages with executable evidence.
The current priority is callable and vector conformance informed by Prompty’s consumer needs, not HTTP transport projection. Prompty is evidence for what must work; Typra’s principles decide what should become the durable contract model. If this reveals a better way to build Prompty with Typra, that is a valid success path, not a regression.
Contract projection roadmap
Section titled “Contract projection roadmap”- Define the Typra contract vocabulary and adoption rules.
- Preserve a Prompty-informed compatibility baseline for load/save, coercion shorthands, named collections, discriminators, provider wire mappings, factories, methods, protocols, and existing load/render/parse vector categories.
- Move callable contracts toward TypeSpec-native
interfaceandop. - Add operation decorators for runtime cancellation, sync signatures, optional operations, and effect metadata.
- Add
@vectorfor callable behavior backed by a callable conformance oracle. - Add shared structural CodeModel and target renderers to reduce per-language emitter duplication.
- Defer HTTP transport projection until callable/vector conformance is proven.
Executable conformance specification
Section titled “Executable conformance specification”The language-neutral runtime semantics contract and save-side executable
conformance oracle are in place. Next steps are to grow more load-side and
negative-path conformance cases across load, JSON helpers, provider wire
mappings, scalar coercions, enums, optionals, nulls, polymorphic dispatch, and
error behavior.
Fixture and shape fuzzing
Section titled “Fixture and shape fuzzing”Generate TypeSpec fixture shapes programmatically by combining nested models, collections, dictionaries, unions, enums, optional fields, aliases, provider mappings, and reserved-word names.
Golden API snapshots
Section titled “Golden API snapshots”Snapshot generated API shape for each target so accidental breaking changes are visible in class names, field names, methods, enum values, package layout, and exported symbols.
Runtime semantics contract
Section titled “Runtime semantics contract”Keep the shared runtime semantics contract current as normalization continues, especially around unknown fields, missing required fields, nulls, coercion failures, enum failures, provider mappings, discriminator dispatch, and native interop delegation.
Production-grade diagnostics
Section titled “Production-grade diagnostics”Emit actionable messages with source locations when TypeSpec shapes cannot be represented cleanly or portably. Distinguish warnings, portability risks, and hard errors.
Consumer smoke projects
Section titled “Consumer smoke projects”Add tiny downstream projects that consume generated output as real packages or modules for TypeScript, Python, Go, Rust, C#, Java, and Swift.
Language polish
Section titled “Language polish”Make each target feel idiomatic without losing cross-language semantic parity: Java package layout and builders, Go richer validation, Rust typed errors, C# nullable annotations, and stricter Python/TypeScript validation options.
Release and compatibility gate
Section titled “Release and compatibility gate”Gate releases on TypeSpec compatibility, language toolchain versions, generated fixture validation, conformance matrix status, consumer smoke projects, and package dry-run validation.
Documentation standard
Section titled “Documentation standard”Keep public docs concise and source-aligned:
- Explain the emitter boundary before target details.
- Prefer runnable configuration over abstract prose.
- Document verifier and metadata behavior wherever generated output is committed.
- Treat fixtures as evidence, not marketing.
- Avoid promising runtime behavior that belongs in consuming products.
Review criteria
Section titled “Review criteria”Every public docs change should answer:
- Does it help users decide whether Typra is the right tool?
- Does it show the shortest safe path to a working generation?
- Does it make review gates and generated-code limits explicit?
- Does it cite behavior that exists in source, fixtures, or package metadata?
- Does it stay concise enough to scan before copying a command?