fix(orchestrator): give pi agents the reportSection handoff field - #1086
Open
Gilbert09 wants to merge 1 commit into
Open
fix(orchestrator): give pi agents the reportSection handoff field#1086Gilbert09 wants to merge 1 commit into
Gilbert09 wants to merge 1 commit into
Conversation
The orchestrator runs every task on the pi harness, and pi's complete_task schema was missing reportSection while the zod/MCP mirror had it. Agents asked for a report section they could not submit, so the warehouse task's finished report never reached the run report. Both schemas now read their field text from one HANDOFF_FIELDS record, and a parity test fails if their field sets diverge again. Also stop hardcoding richLinks: false on the orchestrator ask bridge. The seeded warehouse task's fallback is handing the user a pre-filled new-source URL, which only works if the overlay renders it as a link they can open or copy.
🧙 Wizard CIRun the Wizard CI and test your changes against wizard-workbench example apps by replying with a GitHub comment using one of the following commands: Test all apps:
Test all apps in a directory:
Test an individual app:
Show more apps
Results will be posted here when complete. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Every agent that runs a warehouse task is told to write a report section it cannot submit, so the section never reaches the user's run report.
complete_taskexists twice: a zod schema for the MCP path, and a typebox mirror for pi. Only the zod one hadreportSection.renderHandoffContextreadshandoff.reportSectionto build the run report, so on pi it always reads nothing.The second problem is the fallback path. When a user cannot hand over a credential, the warehouse task gives them the pre-filled new-source URL. The orchestrator ask bridge hardcoded
richLinks: false, so that URL rendered as plain text with no way to open or copy it.Changes
reportSectionto the picomplete_taskschema.HANDOFF_FIELDSrecord that both schemas read.HANDOFF_FIELDSagainstkeyof Required<TaskHandoff>, so a new field on the interface fails the typecheck until it is described.ProgramRunintorunOrchestratorand readrichLinksfrom it, instead of hardcoding false.richLinks: trueonposthog-integration, the only program the orchestrator route serves.I kept the two schemas separate rather than generating one from the other. Zod carries length caps that typebox does not, and pi must stay out of the static module graph. The parity test is the cheaper guard.
Test plan
handoff-schema-parity.test.tsfails if the two harnesses'complete_taskfield sets diverge again. That is the regression this PR fixes, and no existing test covered it.tsc --noEmitoutput before and after. Same errors, all pre-existing onmain.richLinks: true. I did not run the TUI.LLM context
I (actually Claude Opus 5) wrote this while investigating why the seeded warehouse task rarely produces a source. The
reportSectiongap surfaced from the agent remarks on the rollout dashboard, then confirmed against the two schema definitions.