Exhaustive type states
Let the type system point to the missing case. TQ Codeworks is a workspace for following state changes through branches, data and the code that handles them.
switch (state.kind) {
case 'ready': return render(state.data);
case 'failed': return showError(state.error);
default: return assertNever(state);
}Connection
Base URL, credentials and a reachable server.
Project
Add a new state in a test change and let the type checker reveal every branch that still needs an implementation.
Review before applying
Compare actual behavior with the expected result. If a check fails, investigate it before applying more changes.
switch (state.kind) {
case 'ready': return render(state.data);
case 'failed': return showError(state.error);
default: return assertNever(state);
}Follow a new state into every affected branch
Adding a state to a TypeScript application is a design decision that spreads beyond its declaration. TQ Codeworks is a Windows AI coding workspace where you can investigate that spread before making the edit. Open the project and explain what the new state means to the user, including what data exists while the application is in it.
The tagged-union example illustrates a useful maintenance request: introduce a state, then examine the rendering branches that must handle it. Ask the assistant to relate its proposed code to the project's actual type definitions and consumers. Compiler feedback can help locate missing cases, but the behavior assigned to each case still needs a product decision. TQ Codeworks is the workspace for that work, not a built-in state migration engine.
Choose a supported model connection, including an unrestricted model if one is available through your OpenAI-compatible or Anthropic endpoint. Credentials may be required, and the model and server determine context and tool support. Review changes to declarations and branches as one proposal, then run your TypeScript checks and the affected interaction tests. Keep the intended transition in the conversation so a patch that compiles can also be assessed for the experience it creates.
State changes beyond the type declaration
What should I specify about the new state?
Describe how the application enters and leaves it, which data it contains and what the user can do there. Those details let you judge the proposed branches by behavior rather than by whether the compiler accepts them.
Will an exhaustive switch find every consumer?
It helps where the code uses exhaustive checking, but does not prove that all consumers follow that pattern. Inspect references and default branches too, then run the project's checks after reviewing the proposed change across relevant files.
Should a new state reuse an existing screen?
Decide from its meaning and permitted actions. Similar appearance can hide different available data or transitions. Ask the assistant to explain the consequences of reuse and inspect whether the implementation preserves those distinctions.
How do I review a type-safe but incorrect patch?
Walk through an actual transition and compare the displayed information and allowed actions with your requirement. A valid type describes a permitted shape; it does not establish that the user reaches the right outcome.
TQ Codeworks · Updated 2026-10-25
