fix: custom workflow now passes the real task to workers (#87)#88
Merged
Payel-git-ol merged 2 commits intoJun 16, 2026
Merged
Conversation
Adding .gitkeep for PR creation (default mode). This file will be removed when the task is complete. Issue: Payel-git-ol#87
…l#87) Custom workflows built in the canvas (Boss -> Managers -> Workers) ran all agents but produced no code. Root cause: decisionFromPredefinedWorkflow set TechnicalDescription to the architecture label ('Custom workflow with Boss and N managers') instead of the user's request. Since that string becomes each worker's TASK.md, workers were told to implement a meaningless label and generated nothing. - TechnicalDescription now carries the real task (title + description); the architecture label stays in ArchitectureNotes for Boss context. - Detect the tech stack from the task when the custom workflow omits it, mirroring the AI-planning path (no more silent Go default). - Fix hasRealCode regression (commit 6f5da02): the '>= 3 lines' threshold rejected valid short source (e.g. minimal main.go), breaking TestContainsSourceCode and orchestrator CI; require >= 1 real code line. Updates TestDecisionFromPredefinedWorkflow and adds a regression test.
c977f42
into
Payel-git-ol:fix/custom-workflow
2 checks passed
Contributor
Author
Working session summaryPR #88 is merged. CI on the PR was green (Go Workspace CI + Orchestrator CI both SUCCESS), and the working tree is clean.
Nothing more to do on this issue — fix is upstream. This summary was automatically extracted from the AI working session output. |
Contributor
Author
🤖 Solution Draft LogThis log file contains the complete execution trace of the AI solution draft process. 💰 Cost estimation:
📊 Context and tokens usage:Claude Opus 4.8: (2 sub-sessions)
Total: (3.7K new + 103.5K cache writes + 3.9M cache reads) input tokens, 24.1K output tokens, $3.222027 cost Claude Opus 4.7:
Total: (13 new + 48.8K cache writes + 95.2K cache reads) input tokens, 805 output tokens, $0.372540 cost 🤖 Models used:
📎 Log file uploaded as Gist (2138KB)Now working session is ended, feel free to review and add any feedback on the solution draft. |
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
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.
🤖 Fix: custom workflow now actually builds the project
Fixes #87
Problem
When a user builds their own workflow on the canvas (Boss → Managers → Workers) and submits a task, Octra ran every agent (the chat showed Coordinator done, Developer done, Designer done…) but produced no code — it "started creating the project and immediately stopped, refusing to write code."
Root cause
decisionFromPredefinedWorkflow(orchestrator/internal/service/rules/boss/plan.go) set theTechnicalDescriptionto the architecture label sent by the frontend:That
TechnicalDescriptionis exactly what becomes each worker'sTASK.md(boss → manager → worker, viaAssignWorkersRequest.TaskMd). So every worker was asked to implement the meaningless label instead of the user's actual request — and generated nothing. The real task (title+description) was silently discarded on the custom-workflow path, even though the AI-planning path always carries a real technical description.Fix
TechnicalDescriptionnow carries the real task (title+description); the architecture label is kept only inArchitectureNotesfor Boss validation/context.detectTechStack, mirroring the AI-planning path — no more silently defaulting every custom workflow to Go.hasRealCode(introduced in6f5da02): the>= 3 non-comment linesthreshold rejected valid short source such as a minimalmain.go(package main+func main() {}) or a one-line Express server. This brokeTestContainsSourceCodeand left orchestrator CI red onmaster. It now requires>= 1real code line while still rejecting empty / comment-only stubs (issue #98 intent preserved).How to reproduce / verify
done, no files are written.Tests
TestDecisionFromPredefinedWorkflow— asserts the technical description holds the real task and the label lives inArchitectureNotes.TestDecisionFromPredefinedWorkflowCarriesRealTask— regression test: the workflow label must not leak into the task, the real request must survive, and the tech stack must be detected (python) when omitted.go build ./...,go vet ./..., andgo test ./...are green for the orchestrator (and the other Go modules build/test clean).