gmc-openspec 1.4.1 → 1.4.2

package/dist/core/jira/templates.js

@@ -155,7 +155,11 @@ ${SHARED_GUARDRAILS}
 ## Writeback Rules
 
 - This is the only Jira intake workflow allowed to write to Jira.
-- Before any Jira comment, child issue creation, link update, or status change, show a concrete diff of the write.
+- Child issue writeback is the default strategy for reviewed stories.
+- For every non-deferred story missing \`stories.<storyId>.jiraIssueKey\` in \`mapping.yaml\`, the writeback plan MUST include a \`createJiraIssue\` operation.
+- Do not create duplicate Jira child issues for stories that already have \`jiraIssueKey\`; plan only needed link, update, or status changes for those stories.
+- Summary comment sync is optional. Do not include a Jira comment by default unless the user explicitly requests one, or there are no child issues to create.
+- Before any child issue creation, link update, status change, field edit, or optional comment, show a concrete diff of the write.
 - Ask for explicit confirmation before each batch of writes.
 - If \`openspec/jira.yaml\` has \`writeback.enabled: false\`, ask the user to confirm this one-time sync before writing.
 - Use only the official Atlassian MCP Jira write tools needed for the confirmed diff: \`addCommentToJiraIssue\`, \`editJiraIssue\`, \`getTransitionsForJiraIssue\`, \`transitionJiraIssue\`, and \`createJiraIssue\`.
@@ -164,10 +168,15 @@ ${SHARED_GUARDRAILS}
 
 1. Run \`openspec jira validate <JIRA-ID> --stage propose --json\` when syncing proposed OpenSpec changes.
 2. Read \`mapping.yaml\`, \`stories.md\`, and current OpenSpec change status.
-3. Prepare a writeback plan: comments, links, child issues, or status moves.
-4. Show the diff and wait for explicit user approval.
-5. Use the named Atlassian MCP write tools only after approval.
-6. Update \`intake.yaml\` status to \`synced\` only after successful writeback.
+3. Identify all non-deferred reviewed stories and split them into:
+   - stories missing \`jiraIssueKey\`, which must be planned as Jira child issues;
+   - stories with \`jiraIssueKey\`, which must not be recreated.
+4. Prepare a child-issue-first writeback plan. For each \`createJiraIssue\`, show the Jira summary, issue type, parent/source issue, description or acceptance criteria, trace links, and corresponding OpenSpec change.
+5. Include an optional summary comment only when the user requested comment sync, or when there are no child issues to create.
+6. Show the full diff and wait for explicit user approval.
+7. Use the named Atlassian MCP write tools only after approval.
+8. After each successful \`createJiraIssue\`, update the matching \`stories.<storyId>.jiraIssueKey\` in \`mapping.yaml\`.
+9. Update \`intake.yaml\` status to \`synced\` only after successful writeback and local mapping updates.
 
 ## Output
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gmc-openspec",
-  "version": "1.4.1",
+  "version": "1.4.2",
   "description": "AI-native system for spec-driven development",
   "keywords": [
     "openspec",