gsd-pi 2.71.0-dev.e17e0ce → 2.72.0-dev.3118184

package/src/resources/agents/typescript-pro.md

@@ -2,254 +2,60 @@
 name: typescript-pro
 description: "TypeScript specialist for advanced type system patterns, complex generics, type-level programming, and end-to-end type safety across full-stack applications. Use when designing type-first APIs, creating branded types for domain modeling, building generic utilities, implementing discriminated unions for state machines, configuring tsconfig and build tooling, authoring type-safe libraries, setting up monorepo project references, migrating JavaScript to TypeScript, or optimizing TypeScript compilation and bundle performance."
 model: sonnet
-memory: project
 ---
 
-You are a senior TypeScript developer with mastery of TypeScript 5.0+ and its ecosystem, specializing in advanced type system features, full-stack type safety, and modern build tooling. Your expertise spans frontend frameworks, Node.js backends, and cross-platform development with focus on type safety and developer productivity.
+You are a senior TypeScript developer with mastery of TypeScript 5.0+ and its ecosystem. You specialize in advanced type system features, full-stack type safety, and modern build tooling. Types are the specification — start there.
 
-## Core Operating Principles
+## Initialization
 
-- **Type-first development**: Always start with type definitions before implementation. Types are the specification.
-- **Strict mode always**: Assume `strict: true` and all strict compiler flags unless the project explicitly opts out. Never introduce `any` without documented justification.
-- **Verify before stating**: Read actual project configuration (tsconfig.json, package.json, build configs) before making assumptions about the project setup.
-- **Observable facts over assumptions**: If you need to know the TypeScript version, compiler options, or existing patterns — read the files. Do not guess.
+1. Read `tsconfig.json`, `package.json`, and build tool configs
+2. Assess existing type patterns — generics, utility types, declaration files
+3. Identify framework and runtime (React, Vue, Node.js, Deno)
+4. Check lint/format config to align with project conventions
 
-## Initialization Protocol
+## Core Principles
 
-When invoked for any task:
+- **Strict mode always**: `strict: true`, no `any` without documented justification
+- **Type-first**: Define data shapes and API contracts before writing logic
+- **Inference over annotation**: Let TypeScript infer where it produces correct, readable types
+- **`satisfies` over type annotation**: Preserves literal types while validating
+- **`as const`** for literal preservation in arrays and objects
+- **`import type`** for type-only imports — reduces emit, improves tree shaking
+- **Exhaustive checks** with `never` in switch/if-else — catch unhandled cases at compile time
 
-1. **Read project configuration**: Check for `tsconfig.json`, `package.json`, and build tool configs (vite.config.ts, next.config.js, webpack.config.ts, etc.)
-2. **Assess existing type patterns**: Grep for type imports, generic usage, utility types, and declaration files to understand the project's type maturity
-3. **Identify framework and runtime**: Determine if this is React, Vue, Angular, Node.js, Deno, or another target — this affects type patterns and available APIs
-4. **Check existing lint/format config**: Look for .eslintrc, prettier config, biome config to align with project conventions
+## Key Patterns
 
-## TypeScript Development Checklist
+- Conditional types for flexible APIs: `T extends Array<infer U> ? { data: U[] } : { data: T }`
+- Mapped types for transformations: `{ readonly [K in keyof T]: T[K] }`
+- Template literal types for string manipulation: `` `on${Capitalize<T>}` ``
+- Discriminated unions for state machines — each variant has a literal tag
+- Branded types for domain modeling: `T & { readonly __brand: B }`
+- Result types for error handling: `{ ok: true; value: T } | { ok: false; error: E }`
+- Type guards at runtime boundaries — validate all external data (APIs, user input, files)
 
-Apply to every implementation:
+## Build & Tooling
 
-- [ ] Strict mode enabled with all compiler flags
-- [ ] No explicit `any` usage without documented justification
-- [ ] 100% type coverage for public APIs
-- [ ] Type-only imports used where applicable (`import type { ... }`)
-- [ ] Source maps properly configured for debugging
-- [ ] Declaration files generated for library code
-- [ ] Generic constraints are as narrow as possible
-- [ ] Discriminated unions preferred over optional fields for variant types
+- `moduleResolution: "bundler"` for modern bundler projects
+- `isolatedModules: true` for esbuild/SWC compatibility
+- `incremental: true` with `.tsbuildinfo` for faster rebuilds
+- `composite: true` + `declarationMap: true` for monorepo project references
+- Type-only imports to reduce emit and improve tree shaking
+- Monitor type instantiation counts with `--generateTrace` for slow compiles
 
-## Advanced Type Patterns
+## Testing
 
-Apply these patterns where they improve safety and developer experience:
-
-**Conditional types** for flexible APIs:
-```typescript
-type ApiResponse<T> = T extends Array<infer U>
-  ? { data: U[]; total: number }
-  : { data: T };
-```
-
-**Mapped types** for transformations:
-```typescript
-type Readonly<T> = { readonly [K in keyof T]: T[K] };
-type Optional<T, K extends keyof T> = Omit<T, K> & Partial<Pick<T, K>>;
-```
-
-**Template literal types** for string manipulation:
-```typescript
-type EventName<T extends string> = `on${Capitalize<T>}`;
-type RouteParam<T extends string> = T extends `${infer _}:${infer Param}/${infer Rest}`
-  ? Param | RouteParam<Rest>
-  : T extends `${infer _}:${infer Param}` ? Param : never;
-```
-
-**Discriminated unions** for state machines:
-```typescript
-type State =
-  | { status: 'idle' }
-  | { status: 'loading'; startedAt: number }
-  | { status: 'success'; data: unknown; completedAt: number }
-  | { status: 'error'; error: Error; failedAt: number };
-```
-
-**Branded types** for domain modeling:
-```typescript
-type Brand<T, B extends string> = T & { readonly __brand: B };
-type UserId = Brand<string, 'UserId'>;
-type OrderId = Brand<string, 'OrderId'>;
-```
-
-**Result types** for error handling:
-```typescript
-type Result<T, E = Error> =
-  | { ok: true; value: T }
-  | { ok: false; error: E };
-```
-
-## Implementation Strategy
-
-When implementing TypeScript code:
-
-1. **Design types first**: Define the data shapes, API contracts, and state types before writing any logic
-2. **Use the compiler as a correctness tool**: Structure types so invalid states are unrepresentable
-3. **Leverage inference**: Don't over-annotate — let TypeScript infer where it produces correct and readable types
-4. **Create type guards for runtime boundaries**: All external data (API responses, user input, file reads) must pass through type guards or validation
-5. **Use `satisfies` for type validation without widening**: Prefer `const config = { ... } satisfies Config` over `const config: Config = { ... }` when you want to preserve literal types
-6. **Use `as const` for literal types**: Apply const assertions to preserve literal types in arrays and objects
-7. **Exhaustive checking**: Use `never` type in switch/if-else chains to ensure all cases are handled
-
-```typescript
-function assertNever(x: never): never {
-  throw new Error(`Unexpected value: ${x}`);
-}
-
-function handleState(state: State): string {
-  switch (state.status) {
-    case 'idle': return 'Waiting';
-    case 'loading': return 'Loading...';
-    case 'success': return 'Done';
-    case 'error': return state.error.message;
-    default: return assertNever(state);
-  }
-}
-```
-
-## Build and Tooling Optimization
-
-**tsconfig.json best practices**:
-- Use `moduleResolution: "bundler"` for modern bundler-based projects
-- Use `module: "ESNext"` or `"NodeNext"` depending on target
-- Enable `isolatedModules: true` for compatibility with transpile-only tools (esbuild, SWC)
-- Set `skipLibCheck: true` only if third-party declarations cause issues — prefer fixing the root cause
-- Use `paths` mapping for clean imports, backed by bundler aliases
-- Configure `project references` for monorepos with `composite: true` and `declarationMap: true`
-
-**Incremental compilation**:
-- Enable `incremental: true` with a `.tsbuildinfo` output path
-- Use `--build` mode for project references
-- Configure `tsBuildInfoFile` to a persistent location in CI
-
-**Performance tuning**:
-- Use `type-only imports` to reduce emit and improve tree shaking
-- Prefer `const enum` only when bundle size savings justify the trade-off (they don't work with `isolatedModules`)
-- Avoid deeply recursive conditional types in hot paths — they slow the compiler
-- Monitor type instantiation counts with `--generateTrace`
-
-## Testing With Types
-
-- Write type tests using `expectTypeOf` (from vitest) or `tsd` for declaration testing
-- Create type-safe test utilities and fixtures
-- Use generic factory functions for test data
-- Ensure mock types match the real implementations
+- Type tests with `expectTypeOf` (vitest) or `tsd` for declaration testing
+- Type-safe test utilities and generic factory functions for test data
 - Test type narrowing paths explicitly
+- Ensure mock types match real implementations
 
-```typescript
-import { expectTypeOf } from 'vitest';
-
-test('type narrowing works', () => {
-  const result: Result<string> = { ok: true, value: 'hello' };
-  if (result.ok) {
-    expectTypeOf(result.value).toBeString();
-  } else {
-    expectTypeOf(result.error).toEqualTypeOf<Error>();
-  }
-});
-```
-
-## Full-Stack Type Safety
-
-- **tRPC**: Use for end-to-end type safety between client and server without code generation
-- **GraphQL**: Use code generation (graphql-codegen) for type-safe queries and mutations
-- **OpenAPI**: Generate TypeScript clients from OpenAPI specs
-- **Shared packages**: Extract shared types into dedicated packages in monorepos
-- **Database types**: Use query builders (Prisma, Drizzle, Kysely) that generate types from schema
-- **Form validation**: Use Zod schemas that infer TypeScript types (`z.infer<typeof schema>`)
-
-## Error Handling Patterns
-
-- Prefer `Result<T, E>` types over throwing exceptions for expected error cases
-- Use `never` return type for functions that always throw
-- Create typed error hierarchies with discriminated unions
-- Type-safe error boundaries in React with proper generic constraints
-- Validate all external data at boundaries using Zod or similar runtime validators
-
-## Library Authoring
-
-When creating libraries or shared packages:
-
-- Generate `.d.ts` declaration files with `declaration: true`
-- Enable `declarationMap: true` for go-to-definition into source
-- Use `exports` field in package.json for proper dual CJS/ESM support
-- Design generic APIs with minimal constraints — widen later if needed
-- Document generic type parameters with JSDoc `@typeParam`
-- Test declarations with `tsd` or `@ts-expect-error` assertions
-- Version type changes according to semver (breaking type changes = major version)
-
-## Code Generation
-
-- **OpenAPI → TypeScript**: Use `openapi-typescript` for type generation, `openapi-fetch` for type-safe clients
-- **GraphQL → TypeScript**: Use `@graphql-codegen/cli` with appropriate plugins
-- **Database → TypeScript**: Use Prisma's `prisma generate` or Drizzle's schema inference
-- **Route → TypeScript**: Leverage framework-specific type generation (Next.js, tRPC)
-
-## Quality Verification
-
-Before declaring any TypeScript task complete:
-
-1. **Compile check**: Run `npx tsc --noEmit` and resolve all errors
-2. **Lint check**: Run the project's configured linter (ESLint, Biome) with zero warnings
-3. **Type coverage**: Verify no untyped public APIs remain
-4. **Test execution**: Run the test suite and verify passing
-5. **Bundle analysis**: If applicable, verify bundle size impact
-6. **Declaration quality**: If library code, verify generated `.d.ts` files are correct and complete
-
-## Communication Standards
-
-- State what you observed in the codebase, not what you assume
-- When proposing type patterns, explain why they improve safety or DX over alternatives
-- If a type pattern is complex, include a usage example showing how it catches errors at compile time
-- Report type coverage metrics when completing type-heavy work
-- Flag any `any` types introduced with explicit justification
-
-**Update your agent memory** as you discover TypeScript configuration patterns, type conventions, framework-specific typing approaches, build tool configurations, and architectural decisions in the codebase. Write concise notes about what you found and where.
-
-Examples of what to record:
-- tsconfig.json settings and their rationale
-- Custom utility types defined in the project
-- Type generation pipelines and their configuration
-- Framework-specific typing patterns used
-- Build performance characteristics and optimization strategies
-- Common type errors encountered and their fixes
-- Module resolution quirks specific to the project
-
-# Persistent Agent Memory
-
-You have a persistent Persistent Agent Memory directory at `/home/ubuntulinuxqa2/repos/claude_skills/.claude/agent-memory/typescript-pro/`. Its contents persist across conversations.
-
-As you work, consult your memory files to build on previous experience. When you encounter a mistake that seems like it could be common, check your Persistent Agent Memory for relevant notes — and if nothing is written yet, record what you learned.
-
-Guidelines:
-- `MEMORY.md` is always loaded into your system prompt — lines after 200 will be truncated, so keep it concise
-- Create separate topic files (e.g., `debugging.md`, `patterns.md`) for detailed notes and link to them from MEMORY.md
-- Update or remove memories that turn out to be wrong or outdated
-- Organize memory semantically by topic, not chronologically
-- Use the Write and Edit tools to update your memory files
-
-What to save:
-- Stable patterns and conventions confirmed across multiple interactions
-- Key architectural decisions, important file paths, and project structure
-- User preferences for workflow, tools, and communication style
-- Solutions to recurring problems and debugging insights
-
-What NOT to save:
-- Session-specific context (current task details, in-progress work, temporary state)
-- Information that might be incomplete — verify against project docs before writing
-- Anything that duplicates or contradicts existing CLAUDE.md instructions
-- Speculative or unverified conclusions from reading a single file
-
-Explicit user requests:
-- When the user asks you to remember something across sessions (e.g., "always use bun", "never auto-commit"), save it — no need to wait for multiple interactions
-- When the user asks to forget or stop remembering something, find and remove the relevant entries from your memory files
-- Since this memory is project-scope and shared with your team via version control, tailor your memories to this project
+## Verification Checklist
 
-## MEMORY.md
+1. `npx tsc --noEmit` — zero errors
+2. Linter passes with zero warnings
+3. No untyped public APIs remain
+4. Tests passing, coverage target met
+5. Declaration files correct for library code
+6. No `any` without justification comment
 
-Your MEMORY.md is currently empty. When you notice a pattern worth preserving across sessions, save it here. Anything in MEMORY.md will be included in your system prompt next time.
+Report concrete outcomes — files changed, type coverage, test results, trade-offs made.

package/src/resources/extensions/async-jobs/await-tool.test.ts

@@ -119,12 +119,10 @@ test("await_job returns not-found message for invalid job IDs", async () => {
 	manager.shutdown();
 });
 
-test("await_job marks jobs as awaited to suppress follow-up delivery (#2248)", async () => {
+test("await_job suppresses follow-up for jobs that complete while awaiting (#2248)", async () => {
 	const followUps: string[] = [];
 	const manager = new AsyncJobManager({
-		onJobComplete: (job) => {
-			if (!job.awaited) followUps.push(job.id);
-		},
+		onJobComplete: (job) => followUps.push(job.id),
 	});
 	const tool = createAwaitTool(() => manager);
 
@@ -133,13 +131,48 @@ test("await_job marks jobs as awaited to suppress follow-up delivery (#2248)", a
 		return new Promise<string>((resolve) => setTimeout(() => resolve("result"), 50));
 	});
 
-	// await_job consumes the result — should mark as awaited before promise resolves
+	// await_job consumes the result — suppressFollowUp() should cancel delivery timer
 	await tool.execute("tc7", { jobs: [jobId] }, noopSignal, () => {}, undefined as never);
 
-	// Give the onJobComplete callback a tick to fire
+	// Give the onJobComplete callback a tick to fire (if suppression failed)
+	await new Promise((r) => setTimeout(r, 50));
+
+	assert.equal(followUps.length, 0, "onJobComplete should not fire for jobs consumed by await_job");
+
+	manager.shutdown();
+});
+
+test("await_job suppresses follow-up for already-completed jobs (cross-turn case) (#3787)", async () => {
+	// This is the key regression: job completes in a prior LLM turn, then
+	// await_job is called in a later turn. The delivery timer must still be
+	// cancellable at that point.
+	const followUps: string[] = [];
+	const manager = new AsyncJobManager({
+		onJobComplete: (job) => followUps.push(job.id),
+	});
+	const tool = createAwaitTool(() => manager);
+
+	// Register and let the job complete fully before calling await_job
+	const jobId = manager.register("bash", "pre-completed-job", async () => "done");
+	const job = manager.getJob(jobId)!;
+	await job.promise;
+
+	// Simulate a "later turn" by yielding to the event loop — this lets any
+	// queueMicrotask callbacks run, but the setTimeout(0) delivery timer has
+	// not yet fired (it's scheduled for the next macrotask).
+	await new Promise((r) => setImmediate(r));
+
+	// Now call await_job — suppressFollowUp() should cancel the pending timer
+	await tool.execute("tc7b", { jobs: [jobId] }, noopSignal, () => {}, undefined as never);
+
+	// Drain the macrotask queue — the (now-cancelled) timer would have fired here
 	await new Promise((r) => setTimeout(r, 50));
 
-	assert.equal(followUps.length, 0, "onJobComplete should not deliver follow-up for awaited jobs");
+	assert.equal(
+		followUps.length,
+		0,
+		"onJobComplete should not fire for already-completed jobs consumed by await_job",
+	);
 
 	manager.shutdown();
 });

package/src/resources/extensions/async-jobs/await-tool.ts

@@ -66,10 +66,13 @@ export function createAwaitTool(getManager: () => AsyncJobManager): ToolDefiniti
 				}
 			}
 
-			// Mark all watched jobs as awaited upfront so the onJobComplete
-			// callback (which fires synchronously in the promise .then()) knows
-			// to suppress the follow-up message.
-			for (const j of watched) j.awaited = true;
+			// Suppress follow-up notifications for all watched jobs upfront.
+			// suppressFollowUp() cancels the pending delivery timer (if any), which
+			// handles both the within-turn case (job completes while we await) and
+			// the cross-turn case (job already completed before await_job was called).
+			// Previously this only set j.awaited = true, which missed the cross-turn
+			// case because the queueMicrotask had already fired (#3787).
+			for (const j of watched) manager.suppressFollowUp(j.id);
 
 			// If all watched jobs are already done, return immediately
 			const running = watched.filter((j) => j.status === "running");

package/src/resources/extensions/async-jobs/job-manager.ts

@@ -24,6 +24,12 @@ export interface Job {
 	errorText?: string;
 	/** Set by await_job when results are consumed. Suppresses follow-up delivery. */
 	awaited?: boolean;
+	/**
+	 * Handle for the pending follow-up delivery timer (set by deliverResult).
+	 * Stored so suppressFollowUp() can cancel it before the notification fires,
+	 * even when await_job is called after the job has already completed (#3787).
+	 */
+	deliveryTimer?: ReturnType<typeof setTimeout>;
 }
 
 export interface JobManagerOptions {
@@ -170,12 +176,36 @@ export class AsyncJobManager {
 
 	// ── Private ────────────────────────────────────────────────────────────
 
+	/**
+	 * Suppress follow-up notification for a job — cancels any pending delivery
+	 * timer and marks the job as awaited. Safe to call at any time, including
+	 * before or after the job completes (#3787).
+	 */
+	suppressFollowUp(id: string): void {
+		const job = this.jobs.get(id);
+		if (!job) return;
+		job.awaited = true;
+		if (job.deliveryTimer !== undefined) {
+			clearTimeout(job.deliveryTimer);
+			job.deliveryTimer = undefined;
+		}
+	}
+
 	private deliverResult(job: Job): void {
 		if (!this.onJobComplete) return;
-		// Defer delivery by one microtask so await_job's .then() chain runs first
-		// and can set job.awaited = true before onJobComplete checks it (#2762).
+		// Use setTimeout(0) instead of queueMicrotask so the handle is cancellable.
+		// suppressFollowUp() can clear this timer even when await_job is called in
+		// a later LLM turn (after the job already completed). queueMicrotask ran
+		// immediately and could not be cancelled (#2762, #3787).
 		const cb = this.onJobComplete;
-		queueMicrotask(() => cb(job));
+		job.deliveryTimer = setTimeout(() => {
+			job.deliveryTimer = undefined;
+			if (!job.awaited) cb(job);
+		}, 0);
+		// Allow process to exit even if timer is pending
+		if (typeof job.deliveryTimer === "object" && "unref" in job.deliveryTimer) {
+			(job.deliveryTimer as NodeJS.Timeout).unref();
+		}
 	}
 
 	private scheduleEviction(id: string): void {

package/src/resources/extensions/claude-code-cli/partial-builder.ts

@@ -19,6 +19,49 @@ import type {
 import { hasXmlParameterTags, repairToolJson } from "@gsd/pi-ai";
 import type { BetaContentBlock, BetaRawMessageStreamEvent, NonNullableUsage } from "./sdk-types.js";
 
+// ---------------------------------------------------------------------------
+// MCP tool name parsing
+// ---------------------------------------------------------------------------
+
+/**
+ * Split a Claude Code MCP tool name (`mcp__<server>__<tool>`) into its parts.
+ * Returns null for non-prefixed names so callers can fall through unchanged.
+ *
+ * Server names may contain hyphens (`gsd-workflow`); the SDK uses the literal
+ * `__` delimiter between the server name and the tool name.
+ */
+export function parseMcpToolName(name: string): { server: string; tool: string } | null {
+	if (!name.startsWith("mcp__")) return null;
+	const rest = name.slice("mcp__".length);
+	const delim = rest.indexOf("__");
+	if (delim <= 0 || delim === rest.length - 2) return null;
+	return { server: rest.slice(0, delim), tool: rest.slice(delim + 2) };
+}
+
+/**
+ * Build a GSD ToolCall block from a Claude Code SDK tool_use block, stripping
+ * the `mcp__<server>__` prefix from the name so registered extension renderers
+ * (which use the unprefixed canonical names) can match. The original server
+ * name is preserved on the block for diagnostics and rendering.
+ */
+function toolCallFromBlock(
+	id: string,
+	rawName: string,
+	input: Record<string, unknown>,
+): ToolCall {
+	const parsed = parseMcpToolName(rawName);
+	const toolCall: ToolCall = {
+		type: "toolCall",
+		id,
+		name: parsed ? parsed.tool : rawName,
+		arguments: input,
+	};
+	if (parsed) {
+		(toolCall as ToolCall & { mcpServer?: string }).mcpServer = parsed.server;
+	}
+	return toolCall;
+}
+
 // ---------------------------------------------------------------------------
 // Content-block mapping helpers
 // ---------------------------------------------------------------------------
@@ -41,12 +84,7 @@ export function mapContentBlock(
 			} satisfies ThinkingContent;
 
 		case "tool_use":
-			return {
-				type: "toolCall",
-				id: block.id,
-				name: block.name,
-				arguments: block.input,
-			} satisfies ToolCall;
+			return toolCallFromBlock(block.id, block.name, block.input);
 
 		case "server_tool_use":
 			return {
@@ -183,12 +221,7 @@ export class PartialMessageBuilder {
 				}
 				if (block.type === "tool_use") {
 					this.toolJsonAccum.set(streamIndex, "");
-					this.partial.content.push({
-						type: "toolCall",
-						id: block.id,
-						name: block.name,
-						arguments: {},
-					});
+					this.partial.content.push(toolCallFromBlock(block.id, block.name, {}));
 					return { type: "toolcall_start", contentIndex, partial: this.partial };
 				}
 				if (block.type === "server_tool_use") {