feat(planning): optional Lerian Map card creation after plan approval#425
Merged
Conversation
…oval Run discovery handshake (product→feature→Desenvolvimento milestone→epic-cards) at the end of planning-small/large-features gates, after plan.md is validated. Persist state to workflow-state.json for running-dev-cycle to reuse. Requested-by: Bruno
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughPlanning skills now require Lerian Map card creation after gate approval, and ChangesLerian Map Card Creation
✨ Finishing Touches✨ Simplify code
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 `@pm-team/skills/planning-large-features/SKILL.md`:
- Around line 143-158: The persisted `workflow-state.json` contract in the
`lerianMap` block needs consistent key names, because the example uses camelCase
(`cardId`, `devMilestoneId`) while the reuse description refers to `card_id`s.
Update the `planning-large-features/SKILL.md` guidance so
`ring:running-dev-cycle` uses one casing scheme end-to-end, and explicitly state
whether `checklistItemIds` are required for the card-revalidation path or only
for initial creation.
In `@pm-team/skills/planning-small-features/SKILL.md`:
- Around line 124-139: The `workflow-state.json` contract in `SKILL.md` is
inconsistent: the `lerianMap` example uses camelCase keys like `cardId` and
`devMilestoneId`, while the reuse description refers to `card_id`s, which makes
the discovery handshake ambiguous. Update the `lerianMap` spec and the
`ring:running-dev-cycle` handshake wording to use one naming convention
consistently throughout, and explicitly state whether `checklistItemIds` are
persisted and reused as part of the contract.
🪄 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: ASSERTIVE
Plan: Pro
Run ID: 46a58bb1-902f-46b5-b904-be55163a1834
📒 Files selected for processing (2)
pm-team/skills/planning-large-features/SKILL.mdpm-team/skills/planning-small-features/SKILL.md
…ning state as source Card creation is now a required final step of planning gates. running-dev-cycle uses pre-existing featureId/card_ids from workflow-state.json when available; falls back to full discovery handshake for backward-compat. Requested-by: Bruno
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 `@dev-team/skills/running-dev-cycle/SKILL.md`:
- Around line 243-244: The primary planning-state path in the running-dev-cycle
logic currently treats lerianMap.cardsCreated as implicit consent and skips any
confirmation, which can silently enable Map sync in the dev cycle. Update the
flow that reads docs/pre-dev/{feature}/workflow-state.json and handles the
lerianMap block so the user is explicitly asked once whether to enable Map sync
for this cycle, or otherwise clearly record that planning card creation implies
consent; keep the adoption of featureId, dev_milestone_id, and cardId/checklist
ids gated on that decision.
- Line 246: The validation path in the running-dev-cycle SKILL currently
re-fetches each task in `VALIDATE` and re-resolves checklist-item IDs, so the
persisted `checklistItemIds` in the `lerianMap` block are unused. Update the
`VALIDATE only` flow to either consume `checklistItemIds` directly from the
persisted mapping when a card still exists, or remove `checklistItemIds` from
the persisted schema and related examples if the fetched-card response should
remain the source of truth. Keep the logic aligned in the `SKILL.md`
planning/validation guidance so the `card_id` and checklist ID handling is
consistent.
🪄 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: ASSERTIVE
Plan: Pro
Run ID: cfd2030a-5660-4700-a663-56a20962852b
📒 Files selected for processing (3)
dev-team/skills/running-dev-cycle/SKILL.mdpm-team/skills/planning-large-features/SKILL.mdpm-team/skills/planning-small-features/SKILL.md
…hecklistItemIds reuse + Map-sync consent Address CodeRabbit review on #425: - Persisted workflow-state.json contract now uses camelCase keys end-to-end (cardId/devMilestoneId/checklistItemIds); note the Map API snake_case mirror. - checklistItemIds documented as part of the reuse contract; dev cycle adopts persisted ids directly (no extra round-trip), re-resolving only on re-create. - Document that planning card creation IS consent to dev-cycle Map sync (no silent escalation; opt out by omitting lerianMap).
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@dev-team/skills/running-dev-cycle/SKILL.md`:
- Around line 243-248: Treat a present `lerianMap` block with `cardsCreated ==
false` as the same fallback path as no `lerianMap` block, so the dev-cycle flow
still runs the full handshake instead of partially skipping map sync. Update the
branching in the planning-state logic to distinguish only “cardsCreated true” as
the primary adopt-existing-cards path, and route both “missing block” and
“cardsCreated false” through the existing fallback handshake steps. Keep the
current primary behavior for `docs/pre-dev/{feature}/workflow-state.json` only
when the `lerianMap` block has created cards.
🪄 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: ASSERTIVE
Plan: Pro
Run ID: 8a3fae4d-86a5-4aa6-8565-f94dc8ad62df
📒 Files selected for processing (3)
dev-team/skills/running-dev-cycle/SKILL.mdpm-team/skills/planning-large-features/SKILL.mdpm-team/skills/planning-small-features/SKILL.md
…handshake A present lerianMap block with cardsCreated:false (Map outage during planning) was neither primary nor fallback. Treat it the same as a missing block so the documented outage-recovery path runs the full card-creation handshake.
brunognovaes
force-pushed
the
feat/planning-map-card-creation
branch
from
5c3a4c1 to
c5f9761
Compare
Contributor
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
dev-team/skills/running-dev-cycle/SKILL.md (1)
241-248: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winUse the canonical persisted key names here.
workflow-state.jsonis documented as camelCase end-to-end, socard_idhere is a contract mismatch. The “re-read the fetched checklist” wording also blurs the source-of-truth rule; keep this path strictly “persisted IDs on the primary path, re-resolve only on recreate.”♻️ Proposed fix
- which now creates the Lerian Map cards as a MANDATORY final step and persists `featureId`, `devMilestoneId`, and the per-epic `card_id`s into `docs/pre-dev/{feature}/workflow-state.json` (`lerianMap` block). + which now creates the Lerian Map cards as a MANDATORY final step and persists `featureId`, `devMilestoneId`, `cardId`, and `checklistItemIds` into `docs/pre-dev/{feature}/workflow-state.json` (`lerianMap` block). - re-read the fetched checklist only to reconcile if the board drifted + re-resolve checklist IDs only when the card must be recreated🤖 Prompt for 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. In `@dev-team/skills/running-dev-cycle/SKILL.md` around lines 241 - 248, The planning-state path in running-dev-cycle/SKILL.md should use the canonical camelCase persisted fields from workflow-state.json, so replace the `card_id` wording with `cardId` when referring to the per-epic card identifiers in the `lerianMap` block. Also tighten the “re-read the fetched checklist” note so it clearly says the primary path adopts the persisted `cardId`/`checklistItemIds` as source of truth, and only re-resolves checklist item IDs when a deleted card is recreated; keep this aligned with the `cardsCreated` adoption flow and `GET /tasks/{id}` validation.
🤖 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.
Outside diff comments:
In `@dev-team/skills/running-dev-cycle/SKILL.md`:
- Around line 241-248: The planning-state path in running-dev-cycle/SKILL.md
should use the canonical camelCase persisted fields from workflow-state.json, so
replace the `card_id` wording with `cardId` when referring to the per-epic card
identifiers in the `lerianMap` block. Also tighten the “re-read the fetched
checklist” note so it clearly says the primary path adopts the persisted
`cardId`/`checklistItemIds` as source of truth, and only re-resolves checklist
item IDs when a deleted card is recreated; keep this aligned with the
`cardsCreated` adoption flow and `GET /tasks/{id}` validation.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 8c161b31-c2db-470c-9784-e4a7ff20f406
📒 Files selected for processing (1)
dev-team/skills/running-dev-cycle/SKILL.md
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.
Moves Lerian Map epic-card creation into the planning workflow as a mandatory completion step, and turns the
running-dev-cyclehandshake into an optional fallback.New design
Planning (
planning-small-features+planning-large-features)plan.mdvalidated.featureId,devMilestoneId, and per-epiccard_ids intodocs/pre-dev/{feature}/workflow-state.json(lerianMapblock) as the contract the dev cycle relies on.cardsCreated: false(or omit the block) so the dev cycle falls back.running-dev-cycle(discovery handshake → OPTIONAL / FALLBACK)workflow-state.jsonhas alerianMapblock (featureId+devMilestoneId+ non-emptycards[]), cards already exist. Skip creation (handshake steps 2–4); only validate eachcard_idviaGET /tasks/{id}, recreating only any that no longer exist. Map sync implicitly enabled — no opt-in re-asked.lerianMapblock exists (planned manually or before this flow), run the FULL handshake exactly as before, including the Lerian Map sync opt-in question. The Map-sync question is asked only on this path.Files changed
pm-team/skills/planning-small-features/SKILL.mdpm-team/skills/planning-large-features/SKILL.mddev-team/skills/running-dev-cycle/SKILL.md