feat: sub-issue lifecycle model — the feature stops auto-closing (ADR 0005)#41
Merged
Conversation
… 0005) Two end-to-end runs showed the feature tracking issue auto-closing mid-pipeline: sdd-spec's and sdd-triage's pull requests reference it and the agent slipped a closing keyword (Closes #N, then Fixes #N) despite the prompt rule forbidding it. A prompt rule failed twice; the fix is structural. A feature is now a tree of sub-issues (ADR 0005): a spec sub-issue, an architecture sub-issue, and one Unit sub-issue per demoable unit, with task sub-issues nested under their Unit. Every pull request closes its own sub-issue; no pull request ever names the feature with a closing keyword, so a slipped Closes/Fixes closes the correct sub-issue rather than the feature. - sdd-spec gains create-issue, link-sub-issue, update-issue: it creates the spec sub-issue, and closes it when the spec pull request merges. - sdd-triage gains update-issue: phase A creates the architecture sub-issue, phase B closes it, phase C nests each task sub-issue under its Unit. - sdd-execute gains update-issue: step 8 closes a Unit once its task sub-issues are all closed, and moves the feature to sdd:done once the spec, architecture, and every Unit sub-issue is closed. A human still does the final close of the feature (ADR 0001). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (6)
📝 WalkthroughWalkthroughThis PR establishes a sub-issue lifecycle model for feature tracking and integrates the ChangesSub-issue lifecycle and agent integration
🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 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 |
![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
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/sdd-execute-haiku.md:
- Around line 306-308: Step 8 currently instructs performing "each" satisfied
transition in one run but conflicts with the workflow's safe-output caps (the
update-issue and add-comment actions are capped at 1). Update the Step 8 text to
require performing satisfied transitions only up to the workflow's safe-output
limits (or explicitly "perform at most one update-issue and at most one
add-comment per run"), leaving remaining satisfied transitions for the next run;
reference the Step 8 rule and the actions named update-issue and add-comment so
the wording aligns with those caps.
In @.github/workflows/sdd-execute-opus.md:
- Around line 306-308: Update the Step 8 text to reflect current tool
limitations: clarify that although multiple transitions may be satisfiable, the
runner can only perform one update-issue and one add-comment call per run, so it
should process at most one completed Unit (or perform only the first satisfiable
transition) and leave remaining transitions for subsequent runs; reference the
Step 8 description and the operations named update-issue and add-comment so
maintainers know to either implement batching support or explicitly limit each
run to a single transition.
In @.github/workflows/sdd-execute-sonnet.md:
- Around line 55-58: The completion-loop wording requires doing "each satisfied
transition in one run" but the `update-issue` action is capped at `max: 1`,
causing a mismatch; change the completion-loop instructions (the text around the
completion-loop / "perform each satisfied transition" sentence) to
single-transition-per-run semantics (e.g., "perform at most one satisfied
transition per run") so it matches the `update-issue` setting, and keep
`update-issue: max: 1` as the intended single-transition-per-run behavior;
update the text references to transitions in the same section so they no longer
imply multiple transitions per run.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 25e1167c-93ef-4937-98b2-3be96e4a51fa
📒 Files selected for processing (11)
.github/workflows/sdd-execute-haiku.lock.yml.github/workflows/sdd-execute-haiku.md.github/workflows/sdd-execute-opus.lock.yml.github/workflows/sdd-execute-opus.md.github/workflows/sdd-execute-sonnet.lock.yml.github/workflows/sdd-execute-sonnet.md.github/workflows/sdd-spec.lock.yml.github/workflows/sdd-spec.md.github/workflows/sdd-triage.lock.yml.github/workflows/sdd-triage.mddecisions/0005-sub-issue-lifecycle-model.md
CodeRabbit flagged that step 8 told the agent to perform every satisfied completion transition in one run, but the update-issue and add-comment safe-outputs are each capped at max 1 — so two completed Units could not both be closed in a single run, and the agent could emit an over-cap, invalid output plan. Step 8 now performs exactly one transition per run — feature completion first, otherwise the oldest completed Unit — and leaves the rest for subsequent runs, which fits the one-call cap. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This was referenced May 19, 2026
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
Two end-to-end runs showed the feature tracking issue auto-closing mid-pipeline.
sdd-spec's spec PR andsdd-triage's architecture PR reference the tracking issue, and the agent slipped a closing keyword for it —Closes #2in run 1,Fixes #17in run 2 — despite ADR 0004's prompt rule forbidding exactly that. A prompt rule has failed twice. The fix has to be structural.Model (ADR 0005)
A feature is a tree of sub-issues:
No pull request ever names the feature tracking issue with a closing keyword. A slipped
Closes/Fixesnow closes the correct sub-issue, not the feature — the failure mode is removed structurally, not re-worded.Changes
create-issue,link-sub-issue,update-issue. Creates the spec sub-issue; closes it when the spec PR merges. The spec PR closes nothing.update-issue. Phase A creates the architecture sub-issue (arch PR closes nothing); phase B closes it; phase C nests each task under its Unit, not the feature.update-issue. Step 8 closes a Unit when its task sub-issues are all closed, and moves the feature tosdd:doneonce the spec, architecture, and every Unit sub-issue is closed. A human still does the final close (ADR 0001).Closing uses the
update-issuesafe-output withstatusenabled (verified against gh-awpkg/workflow/update_issue.go). The leaf task sub-issue still closes via its implementation PR'sCloses #<task>— the one correct closing keyword, because the task pre-exists the PR.Acceptance
gh aw compile— 0 errors, allupdate-issuesafe-outputs compiled into the locks.markdownlint— clean. End-to-end validation on a fixture is the next step.🤖 Generated with Claude Code