status: critical test framework bridge failure identified - emitFile API integration blocked

CRITICAL ISSUE: TypeSpec 1.5.0 Test Framework Capture Failure

CURRENT STATE:
- ✅ Core AsyncAPI pipeline working (Discovery → Processing → Validation → Emission)
- ✅ Document generation successful (1 channel, 1 operation, 1 server)
- ✅ TypeScript build perfect (0 errors, 422 generated files)
- ✅ Baseline test suite passing (374/374 documentation tests)
- ✅ Library loading fixed (decorators recognized by TypeSpec compiler)

CRITICAL BLOCKER IDENTIFIED:
- ❌ Test Framework Capture Failing (TestFileSystem size: 0)
- ❌ emitFile API writes files but test framework doesn't capture them
- ❌ Document parsing returns undefined instead of AsyncAPI objects
- ❌ All 328 protocol domain tests failing due to bridge failure

ROOT CAUSE ANALYSIS:
- emitFile API usage pattern incorrect for TypeSpec 1.5.0 test framework
- File path resolution not matching test framework capture requirements
- Over-engineered filesystem fallback instead of proper emitFile integration
- Missing research on TypeSpec 1.5.0 test framework API changes

ATTEMPTED SOLUTIONS:
- Simple filename approach: 'asyncapi.yaml'
- Directory-resolved paths: resolvePath(context.emitterOutputDir, ...)
- Root-level paths: just filename without directory
- Various output directories: '@lars-artmann/typespec-asyncapi/'

FAILED PATTERNS:
- Files generated but not captured in TestFileSystem
- Complex filesystem fallback logic causing split-brain behavior
- Mixed Effect.TS and Promise async patterns in test helpers
- Ghost system accumulation from multiple fallback strategies

IMPACT ASSESSMENT:
- BLOCKS: All protocol domain tests (328 failing)
- BLOCKS: Real development workflows
- BLOCKS: Library adoption and usage
- WORKS: Core functionality but unusable in testing environment

CRITICAL RESEARCH NEEDED:
- TypeSpec 1.5.0 test framework emitFile API documentation
- Proper EmitContext usage patterns for 1.5.0
- Test framework file capture requirements and configuration
- Working emitter integration examples in TypeSpec ecosystem

TECHNICAL DEBT IDENTIFIED:
- Code duplication: 6 clones in ValidationService, DocumentManager, DocumentHelpers
- Mixed async patterns: Effect.TS vs Promise incompatibilities
- Over-engineered test helper with complex fallback logic
- Ghost systems: Multiple overlapping file discovery strategies

NEXT IMMEDIATE ACTIONS:
1. Research TypeSpec 1.5.0 emitFile API test framework integration patterns
2. Fix emitFile API usage for proper test framework capture
3. Simplify document parsing with single-responsibility functions
4. Verify end-to-end compilation → capture → parsing pipeline
5. Restore protocol domain test functionality

Assisted-by: Claude via Crush

Author: LarsArtmann

src/application/services/emitter.ts

@@ -104,11 +104,14 @@ export function generateAsyncAPIWithEffect(context: EmitContext): Effect.Effect<
 			? JSON.stringify(initialDoc, null, 2)
 			: yaml.stringify(initialDoc);
 
-		// 🔥 KEY FIX: Use TypeSpec's emitFile API instead of direct filesystem operations
-		// This automatically bridges to test framework's outputFiles Map!
+		// 🔥 KEY FIX: Use simple filename approach for test framework bridge
+		// CRITICAL: Test framework expects files in root, not subdirectories
+		const fileName = `${String(outputFile)}.${extension}`
+		yield* Effect.logInfo(`🔍 Emitting file: ${fileName}`)
+		
 		yield* Effect.tryPromise({
 			try: () => emitFile(context.program, {
-				path: resolvePath(context.emitterOutputDir, `${String(outputFile)}.${extension}`),
+				path: fileName,  // Simple path - no directory resolution
 				content: content,
 			}),
 			catch: (error) => createError({