Workflow orchestrator hardening

[cryptosebek]

Workflow orchestrator hardening

Summary

• Load project .env values for workflow subagents and add .env.example.
• Ignore local secrets and generated workflow session files.
• Harden workflow control flow:
  • pause correctly on PM clarification
  • resume the same wave after clarification
  • centralize wave resolution for start and resume
  • reset transient state on stop/session lifecycle events
  • make stop wait for shutdown cleanly
  • keep /workflow stop-task task-scoped
• Move retry enforcement into the engine so maxRetries is enforced there.
• Fix PM agent error handling so model/provider failures surface directly instead of becoming a misleading PM output missing wave error.
• Use the OpenRouter model ID accepted by Pi for PM, developer, and verifier agents.
• Add regression tests for:
  • engine retry limits
  • clarification wait/resume behavior
  • start-path clarification flow
  • project env loading for subagents

[hlibr]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Bravo.

ℹ️ 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".

[hlibr]

I don't think that this extension should handle secrets - pi already does that.

Using .env in general - I don't see much point except for slight convinience at the expense of codebase complexity. Additionally, the user will probably have his own project .env in the project root. Loading that for the extension might lead to unexpected results (what if user's project also uses OPENROUTER_API_KEY, for example?) and privacy concerns.