Gate 4: Reading pipeline observability#23
Conversation
Add contract-aware observability inventory and projection for ReadNeedComprehensionSynthesis and ReadFitsFindingSynthesis, stamp sandbox harness stream events with PTRR and ThricifiedGeneration metadata, and surface those fields through the Terminal execution stream UI. Update V29 spec, parity, docs, Gate 4 checker, CI wiring, and focused package/UAPI tests for the Reading telemetry closure criteria.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Normalize PTRR step-id parsing so the stricter UAPI TypeScript build receives a concrete string before checking Reading pipeline telemetry step names. Validation: pnpm -C uapi exec tsc --noEmit; pnpm run check:v29-gate4; pnpm --dir uapi exec jest --runTestsByPath tests/terminalPipelineHarnessClient.test.ts tests/pipelineExecutionLogHeader.test.tsx --runInBand; pnpm exec eslint packages/pipelines/asset-pack/src/reading-pipeline-observability.ts uapi/app/terminal/terminal-pipeline-harness-client.ts uapi/components/base/bitcode/execution/pipeline-execution-log-header.tsx uapi/components/base/bitcode/execution/pipeline-execution-log.tsx --ext .ts,.tsx; git diff --check
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 987595c891
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| inputType: tool?.inputType || matchedTrace?.inputType || null, | ||
| outputType: tool?.outputType || matchedTrace?.outputType || null, | ||
| returnType: matchedTrace?.returnType || null, | ||
| outputSchema: matchedTrace?.outputType || tool?.outputType || matchedTrace?.returnType || null, |
There was a problem hiding this comment.
Prefer tool schema when projecting tool telemetry
Update resolveReadingPipelineTelemetryProjection so outputSchema prefers tool?.outputType before the PTRR step output type. As written, tool events (for example ReadFitsFindingSynthesis.tool.vector-depository-search) are projected with the step schema (DepositoryFitsResult) instead of the tool schema (EmbeddingSearchResult), which makes the new terminal/log observability output report incorrect contract types for tool telemetry.
Useful? React with 👍 / 👎.
Summary
Validation