fix: add mandatory post-verdict status update steps to task workflows#550
Open
csjusto wants to merge 4 commits intoSynkraAI:mainfrom
Open
fix: add mandatory post-verdict status update steps to task workflows#550csjusto wants to merge 4 commits intoSynkraAI:mainfrom
csjusto wants to merge 4 commits intoSynkraAI:mainfrom
Conversation
|
@csjusto is attempting to deploy a commit to the Pedro Valério Lopez's projects Team on Vercel. A member of the Team first needs to authorize it. |
WalkthroughAdded mandatory status-transition steps and Change Log requirements to three developer task documents, and updated handoff conditions to reference the new status values and outcome-specific actions across QA, validation, and development workflows. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested labels
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Welcome to aios-core! Thanks for your first pull request.
What happens next?
- Automated checks will run on your PR
- A maintainer will review your changes
- Once approved, we'll merge your contribution!
PR Checklist:
- Tests pass (
npm test) - Linting passes (
npm run lint) - Commit messages follow Conventional Commits
Thanks for contributing!
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
.aios-core/development/tasks/validate-next-story.md (1)
472-488: Add explicit failure handling for invalid status/change-log state before mutation.The step is mandatory, but it doesn’t say what to do if the story is not currently
Draftor ifChange Logis missing. Add a guard to prevent silent/incorrect transitions.Suggested enhancement
#### IF verdict is GO (score >= 7): +0. **Pre-check (blocking):** + - If current Status is not `**Draft**`, HALT and log: "Cannot apply GO transition: expected Draft." + - If Change Log section is missing, HALT and request user to restore template structure. 1. **Update story Status field** in the story file: change `**Draft**` to `**Ready**` 2. **Add Change Log entry:** - ``` + ```text | {today's date} | {next version} | Validated GO ({score}/10) — Status: Draft → Ready | `@po` | ``` 3. **Log:** "✅ Story status updated: Draft → Ready" #### IF verdict is NO-GO (score < 7): +0. **Pre-check (blocking):** + - If current Status is not `**Draft**`, HALT and log: "Cannot apply NO-GO outcome: expected Draft." + - If Change Log section is missing, HALT and request user to restore template structure. 1. **Keep** story Status as `**Draft**` 2. **Add Change Log entry:** - ``` + ```text | {today's date} | {next version} | Validation NO-GO — {reason summary} | `@po` | ```As per coding guidelines,
.aios-core/development/tasks/**: "Ensure task has proper error handling guidance."🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aios-core/development/tasks/validate-next-story.md around lines 472 - 488, Add explicit pre-check guards before mutating story Status and Change Log in the "IF verdict is NO-GO (score < 7)" and "IF verdict is GO (score >= 7)" flows: verify the existing Status field equals "**Draft**" and that a Change Log section exists; if either check fails, HALT the task and emit clear logs like "Cannot apply GO outcome: expected Draft." or "Change Log missing: restore template structure before applying validation" so transitions are blocked instead of applied silently; update the steps under both headings to include these blocking pre-checks and corresponding error log messages.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.aios-core/development/tasks/qa-gate.md:
- Around line 465-468: Add an explicit handoff alternative for the CONCERNS
verdict: within the same alternatives block that contains "agent: `@dev`, command:
*apply-qa-fixes" and "agent: `@po`, command: *close-story {story-id}", add a new
alternative with "agent: `@po`, command: *review-concerns {story-id}, condition:
QA gate verdict is CONCERNS (status updated to Done)" so the CONCERNS path is
routed to the PO for review/closure.
- Around line 433-453: Update the three fenced code blocks in the QA Gate
status-update examples under the "IF verdict is PASS/FAIL/WAIVED" sections in
.aios-core/development/tasks/qa-gate.md to specify a language for the fences
(use "text") so markdownlint MD040 is satisfied; specifically change the three
triple-backtick blocks shown in the PASS, FAIL, and WAIVED examples to use
```text instead of ``` while leaving the inner table lines unchanged and ensure
the modified blocks remain under their respective headings/labels.
In @.aios-core/development/tasks/validate-next-story.md:
- Around line 476-487: The two unlabeled fenced code blocks showing example
table rows (the blocks containing "| {today's date} | {next version} |
Validated..." and "| {today's date} | {next version} | Validation NO-GO...")
should be labeled with a language to satisfy markdownlint MD040; update those
fence openings to use "```text" instead of plain "```" so the example rows are
treated as text code-fences (no other content changes required).
---
Nitpick comments:
In @.aios-core/development/tasks/validate-next-story.md:
- Around line 472-488: Add explicit pre-check guards before mutating story
Status and Change Log in the "IF verdict is NO-GO (score < 7)" and "IF verdict
is GO (score >= 7)" flows: verify the existing Status field equals "**Draft**"
and that a Change Log section exists; if either check fails, HALT the task and
emit clear logs like "Cannot apply GO outcome: expected Draft." or "Change Log
missing: restore template structure before applying validation" so transitions
are blocked instead of applied silently; update the steps under both headings to
include these blocking pre-checks and corresponding error log messages.
ℹ️ Review info
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.aios-core/development/tasks/qa-gate.md.aios-core/development/tasks/validate-next-story.md
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.aios-core/development/tasks/dev-develop-story.md:
- Around line 948-951: The document introduces a mandatory status flow ending at
"InReview" but other sections still reference "Ready for Review", causing
conflicting status transitions; search for all occurrences of the literal "Ready
for Review" (including in the completion checklist and the "self-healing
purpose" text) and replace or reword them to align with the new mandatory state
"InReview" (or add clear mapping notes if "Ready for Review" must remain as a
legacy term), update any task completion checks or handoff instructions that
trigger status updates to set "InReview" instead of "Ready for Review", and
verify the updated task follows AIOS task format with explicit elicitation
points mentioned in the doc.
- Around line 926-929: The pre-check logic that currently HALTs when Status is
not `Ready` should be adjusted to treat `InProgress` as an idempotent no-op: in
the "Pre-check (blocking)" guard allow the transition to proceed if current
Status is `Ready` OR `InProgress`, logging a message like "Resuming development:
status already InProgress" for the latter; keep blocking for any other states
and preserve the Change Log template validation. Update the "Update story Status
field" step so it only changes `Ready`→`InProgress` when current Status is
`Ready`, and does nothing when current Status is already `InProgress` (but still
validate and emit error guidance when halting).
Comment on lines
+926
to
+929
| 0. **Pre-check (blocking):** | ||
| - If current Status is not `**Ready**`, HALT and log: "Cannot start development: expected Ready, found {current status}." | ||
| - If Change Log section is missing, HALT and request user to restore template structure. | ||
| 1. **Update story Status field:** change `**Ready**` to `**InProgress**` |
There was a problem hiding this comment.
Make the start transition idempotent for resume scenarios.
Blocking when status is already InProgress can halt legitimate resumed development runs. Consider allowing InProgress as a no-op continuation path, while still blocking invalid states.
Suggested guard adjustment
-0. **Pre-check (blocking):**
- - If current Status is not `**Ready**`, HALT and log: "Cannot start development: expected Ready, found {current status}."
+0. **Pre-check (blocking):**
+ - If current Status is `**Ready**`, continue with transition to `**InProgress**`.
+ - If current Status is `**InProgress**`, continue (resume mode; do not re-transition).
+ - Otherwise, HALT and log: "Cannot start development: expected Ready/InProgress, found {current status}."🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.aios-core/development/tasks/dev-develop-story.md around lines 926 - 929,
The pre-check logic that currently HALTs when Status is not `Ready` should be
adjusted to treat `InProgress` as an idempotent no-op: in the "Pre-check
(blocking)" guard allow the transition to proceed if current Status is `Ready`
OR `InProgress`, logging a message like "Resuming development: status already
InProgress" for the latter; keep blocking for any other states and preserve the
Change Log template validation. Update the "Update story Status field" step so
it only changes `Ready`→`InProgress` when current Status is `Ready`, and does
nothing when current Status is already `InProgress` (but still validate and emit
error guidance when halting).
Comment on lines
+948
to
+951
| ### Rationale | ||
|
|
||
| Status transitions defined in `story-lifecycle.md` are advisory (contextual rules). These steps make them imperative (procedural), ensuring agents always execute the transitions as part of the workflow rather than relying on contextual rule awareness. | ||
|
|
There was a problem hiding this comment.
Resolve remaining “Ready for Review” instructions to avoid contradictory status flow.
This new mandatory flow ends at InReview, but other sections still instruct Ready for Review (for example, the completion checklist and self-healing purpose text). That conflict can cause incorrect final status updates and wrong handoff behavior.
Suggested follow-up patch
-### Ready for Review Criteria (All Modes)
+### InReview Criteria (All Modes)
-8. Set story status: "Ready for Review"
+8. Set story status: "InReview"
-**Purpose**: Catch and auto-fix code quality issues before marking story as "Ready for Review"
+**Purpose**: Catch and auto-fix code quality issues before marking story as "InReview"
-✅ Story ready for review
+✅ Story moved to InReviewAlso applies to: 957-957
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.aios-core/development/tasks/dev-develop-story.md around lines 948 - 951,
The document introduces a mandatory status flow ending at "InReview" but other
sections still reference "Ready for Review", causing conflicting status
transitions; search for all occurrences of the literal "Ready for Review"
(including in the completion checklist and the "self-healing purpose" text) and
replace or reword them to align with the new mandatory state "InReview" (or add
clear mapping notes if "Ready for Review" must remain as a legacy term), update
any task completion checks or handoff instructions that trigger status updates
to set "InReview" instead of "Ready for Review", and verify the updated task
follows AIOS task format with explicit elicitation points mentioned in the doc.
nikolasdehor
approved these changes
Mar 5, 2026
Contributor
nikolasdehor
left a comment
nikolasdehor
left a comment
There was a problem hiding this comment.
Esta PR resolve um problema real de execução: as transições de status definidas em story-lifecycle.md eram advisory (carregadas contextualmente por paths) mas os agentes executam tasks de forma procedural — então as transições eram consistentemente ignoradas. Torná-las imperativas dentro dos próprios task files é a abordagem correta.
Acompanhei o PR #543 de @vxavierr (qa-gate status update), que aprovei anteriormente. Esta PR cobre um escopo mais amplo: além do qa-gate.md, adiciona transições ao validate-next-story.md e ao dev-develop-story.md, e inclui os pre-checks bloqueantes. As mudanças são complementares, sem conflito direto — mas se ambos forem merged, haverá duplicação no qa-gate.md. Recomendo verificar o estado do PR #543 antes de fazer merge desta.
Pontos técnicos:
validate-next-story.md — Step 12:
- Pre-check bloqueante no status
Draftantes de aplicar GO/NO-GO é correto. - Manter o status como
Draftno NO-GO (em vez de regressão) está alinhado ao ciclo de vida esperado.
qa-gate.md — Post-Gate Status Update:
- Cobertura dos 4 vereditos (PASS, CONCERNS, FAIL, WAIVED) é completa.
- A distinção CONCERNS → Done (em vez de InProgress) é uma decisão de produto — assumindo que o PO revisará concerns separadamente, faz sentido.
dev-develop-story.md — Status Transitions:
- Pre-check em
Readyantes de iniciar desenvolvimento e emInProgressantes de marcar comoInReviewfecha o ciclo do @dev corretamente. - A padronização de
"Ready for Review"→"InReview"alinha o texto com os valores reais do campo de status.
Detalhe menor:
Os arquivos qa-gate.md e validate-next-story.md terminam sem newline final (\ No newline at end of file). Adicionar \n ao final evita ruído em diffs futuros.
No geral, PR bem fundamentado e com escopo claro. LGTM condicionado à verificação de conflito com #543.
validate-next-story.md and qa-gate.md define complete validation workflows but lack imperative steps to update story status after verdict. Status transitions are defined in story-lifecycle.md (advisory rules) but agents follow task files procedurally and skip advisory rules not embedded in the workflow. Added: - Step 12 to validate-next-story.md: Draft → Ready on GO, keep Draft on NO-GO - Post-Gate Status Update to qa-gate.md: InReview → Done on PASS/CONCERNS/WAIVED, InReview → InProgress on FAIL Both steps include Change Log entry requirements and rationale explaining the advisory vs imperative gap. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Add pre-check guards before status mutations (verify current status and Change Log section exist before transitioning) - Add language labels to fenced code blocks (```text) for markdownlint MD040 - Add explicit handoff alternative for CONCERNS verdict routing to @po Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The @dev task workflow set status to "Ready for Review" (non-standard) instead of following the story-lifecycle.md transitions: - Ready → InProgress (on development start) - InProgress → InReview (on development complete) Added: - Status Transitions section with pre-checks, Change Log entries, and logging for both start and completion transitions - Updated all 3 execution modes (YOLO, Interactive, Pre-Flight) to reference InReview instead of Ready for Review - Updated handoff condition to reflect correct status Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Make InProgress pre-check idempotent for resume scenarios (dev-develop-story) - Rename "Ready for Review" to "InReview" for status consistency (dev-develop-story) - Add CONCERNS to PASS handoff condition (qa-gate) - Fix trailing whitespace in qa-gate and validate-next-story Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
csjusto
force-pushed
the
fix/task-workflow-status-transitions
branch
from
247aa48 to
06b284a
Compare
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
2 participants
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.
Summary
validate-next-story.md,qa-gate.md) lack imperative steps to update story status after verdictstory-lifecycle.md(advisory/contextual rules) but agents follow task files procedurally and skip rules not embedded in the workflowChanges
validate-next-story.md— New Step 12: Post-Validation Status UpdateDraft → Ready+ Change Log entryDraft+ Change Log entryqa-gate.md— New section: Post-Gate Status UpdateInReview → Done+ Change Log entryInReview → InProgress+ Change Log entryInReview → Done+ Change Log entryRoot Cause
Rules in
.claude/rules/story-lifecycle.mdare advisory — loaded contextually when editing files matchingpaths:patterns. Tasks in.aios-core/development/tasks/are imperative — executed step-by-step by agents as recipes. Since status transitions only existed in advisory rules, agents consistently skipped them during workflow execution.Test plan
*validate-story-drafton a Draft story → verify status changes to Ready on GO*qa-gateon an InReview story → verify status changes to Done on PASS*qa-gateon an InReview story → verify status changes to InProgress on FAIL🤖 Generated with Claude Code
Summary by CodeRabbit