cc-agentic-framework 1.14.1

package/framework/modules/backlog/module.json

@@ -0,0 +1,82 @@
+{
+  "$schema": "../core/registries/schemas/module.schema.json",
+  "id": "backlog",
+  "version": "1.8.1",
+  "name": "Backlog Management",
+  "description": "Ticket-based backlog management with Jira-like workflow, milestone tracking, and sprint organization",
+  "provides": {
+    "agents": [
+      "ai-backlog-manager"
+    ],
+    "skills": [
+      "building-tickets",
+      "organizing-backlog"
+    ],
+    "capabilities": [
+      "ticket-decomposition",
+      "ticket-writing",
+      "jira-formatting",
+      "epic-breakdown",
+      "sprint-planning",
+      "milestone-tracking",
+      "organizing-backlog-knowledge",
+      "backlog-workflow",
+      "ticket-lifecycle"
+    ],
+    "scripts": [],
+    "cli-commands": [
+      {
+        "name": "backlog create-ticket",
+        "type": "create",
+        "skill": "building-tickets",
+        "template": "ticket.md.template",
+        "description": "Create a new ticket from template"
+      },
+      {
+        "name": "backlog validate",
+        "type": "validate",
+        "skill": "building-tickets",
+        "schema": "ticket.schema.json",
+        "description": "Validate ticket files against v10.1.1 standards"
+      },
+      {
+        "name": "backlog import",
+        "type": "import",
+        "skill": "organizing-backlog",
+        "description": "Import tickets from Jira"
+      },
+      {
+        "name": "backlog migrate-milestones",
+        "type": "migrate",
+        "skill": "organizing-backlog",
+        "description": "Migrate milestone structure"
+      },
+      {
+        "name": "backlog update-fields",
+        "type": "update",
+        "skill": "organizing-backlog",
+        "description": "Update ticket field mappings"
+      }
+    ]
+  },
+  "requires": {},
+  "optional-dependencies": [
+    "core",
+    "jira"
+  ],
+  "context": {
+    "process": [
+      "backlog-workflow.md"
+    ]
+  },
+  "metadata": {
+    "category": "workflow",
+    "keywords": [
+      "backlog",
+      "tickets",
+      "sprints",
+      "milestones",
+      "agile"
+    ]
+  }
+}

package/framework/modules/backlog/schemas/ticket.schema.json

@@ -0,0 +1,143 @@
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "title": "Backlog Ticket Schema",
+  "description": "JSON Schema for validating backlog ticket YAML frontmatter (v10.1.1 specification)",
+  "type": "object",
+  "required": ["documentType", "title", "description", "createdDate"],
+  "properties": {
+    "documentType": {
+      "type": "string",
+      "enum": ["story", "task", "bug", "spike", "epic"],
+      "description": "Type of the ticket"
+    },
+    "title": {
+      "type": "string",
+      "minLength": 10,
+      "maxLength": 255,
+      "description": "Clear, descriptive ticket title"
+    },
+    "description": {
+      "type": "string",
+      "minLength": 10,
+      "maxLength": 500,
+      "description": "One-sentence summary"
+    },
+    "milestone": {
+      "type": ["string", "null"],
+      "pattern": "^(Nov|Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Dec)\\d{4}$",
+      "description": "Milestone code (e.g., Feb2026)"
+    },
+    "priority": {
+      "type": ["string", "null"],
+      "enum": ["P0", "P1", "P2", null],
+      "description": "Priority level"
+    },
+    "storyPoints": {
+      "type": ["integer", "null"],
+      "enum": [1, 2, 3, 5, 8, 13, null],
+      "description": "Story points (Fibonacci: 1,2,3,5,8,13)"
+    },
+    "labels": {
+      "type": ["array", "null"],
+      "items": {
+        "type": "string",
+        "pattern": "^[a-z0-9-]+$"
+      },
+      "description": "Array of labels (lowercase kebab-case)"
+    },
+    "createdDate": {
+      "type": "string",
+      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+      "description": "Creation date (YYYY-MM-DD)"
+    },
+    "exportedDate": {
+      "type": ["string", "null"],
+      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+      "description": "Date when exported to Jira (YYYY-MM-DD)"
+    },
+    "jira-ticketId": {
+      "oneOf": [
+        {
+          "type": "string",
+          "pattern": "^[A-Z]+-\\d+$"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Jira ticket ID (e.g., DAPM-1234)"
+    },
+    "jira-url": {
+      "type": ["string", "null"],
+      "format": "uri",
+      "description": "Jira ticket URL"
+    },
+    "jira-parent": {
+      "oneOf": [
+        {
+          "type": "string",
+          "pattern": "^[A-Z]+-\\d+$"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Parent epic ticket ID"
+    },
+    "jira-related": {
+      "type": ["array", "null"],
+      "items": {
+        "type": "string",
+        "pattern": "^[A-Z]+-\\d+$"
+      },
+      "description": "Array of related ticket IDs"
+    },
+    "jira-blocking": {
+      "type": ["array", "null"],
+      "items": {
+        "type": "string",
+        "pattern": "^[A-Z]+-\\d+$"
+      },
+      "description": "Array of tickets this blocks"
+    },
+    "jira-blockedBy": {
+      "type": ["array", "null"],
+      "items": {
+        "type": "string",
+        "pattern": "^[A-Z]+-\\d+$"
+      },
+      "description": "Array of tickets blocking this"
+    },
+    "jira-fixVersion": {
+      "type": ["string", "null"],
+      "description": "Release version linking"
+    },
+    "jira-internalNotes": {
+      "type": ["string", "null"],
+      "description": "Internal process notes"
+    },
+    "framework-documentation": {
+      "type": ["string", "null"],
+      "description": "Cross-repo documentation references (@repo-name/path)"
+    },
+    "framework-milestone": {
+      "type": ["string", "null"],
+      "description": "Local milestone file path"
+    },
+    "framework-technicalGuides": {
+      "type": ["array", "null"],
+      "items": {
+        "type": "string"
+      },
+      "description": "Technical documentation references"
+    },
+    "framework-relatedLocal": {
+      "type": ["array", "null"],
+      "items": {
+        "type": "string"
+      },
+      "description": "Local file references"
+    }
+  },
+  "additionalProperties": true
+}

package/framework/modules/backlog/skills/backlog/building-tickets/BODY-STRUCTURE.md

@@ -0,0 +1,470 @@
+# Ticket Body Structure (v10.1.1)
+
+## Overview
+
+All ticket bodies use **native markdown** (NOT Jira wiki markup) with exactly **2 H2 sections** and **--- dividers**.
+
+```
+# H1 Title
+---
+## Description
+[content]
+---
+## Acceptance Criteria
+[content]
+```
+
+---
+
+## Complete Template
+
+### Story/Task Template
+
+```markdown
+# APM-R: FE: Dashboard: Configurable Cards
+
+---
+
+## Description
+
+**AS** a user,
+**I WANT** to customize my dashboard with selectable cards,
+**SO THAT** I can focus on metrics that matter to me.
+
+**Context:**
+
+Polling is chatty, delayed, and harder to scale. We shaped the data layer to be
+subscription-ready; this story implements push updates for real-time status
+without altering page components.
+
+Related ticket: [DAPM-1032](https://{your-org}.atlassian.net/browse/PROJ-1032)
+
+**Requirements:**
+
+* Expose GraphQL subscription for status events (started/progress/completed/failed)
+* Switch data layer to subscription transport
+* Standardize connection: single active subscription per context, clean unsubscribe, reconnect with backoff
+* Enforce tenant isolation via org context from session/claims
+
+**Technical Notes:**
+
+* Use Apollo Client subscriptions pattern (already established in codebase)
+* Performance target: <100ms latency for status updates
+* Coordinate with data team on subscription schema changes
+* Monitor WebSocket connection health
+
+---
+
+## Acceptance Criteria
+
+* **Verify** users receive real-time status updates via push (not polling)
+* **Verify** GraphQL subscription includes all required fields
+* **Verify** single active subscription per context (no duplicates)
+* **Verify** unsubscribe cleanup prevents memory leaks
+* **Verify** reconnect logic with backoff handles network issues
+* **Verify** tenant isolation enforced (user sees only their org data)
+* **Verify** performance acceptable (<100ms latency)
+* **Verify** error states handled gracefully
+* **Verify** works on desktop, tablet, mobile viewports
+* **Verify** documentation updated with subscription pattern
+```
+
+### Epic Template
+
+```markdown
+# APM-R: Risk Analytics: Scenario Analysis Engine
+
+---
+
+## Description
+
+**Business Value:**
+
+Users need to understand how risks change under different market scenarios. This
+epic enables rapid scenario modeling without leaving the platform, reducing time
+to insight from hours to minutes and improving decision quality.
+
+**Technical Scope:**
+
+Implement configurable scenario builder with real-time delta calculation across
+all components. Architecture uses immutable scenario state and parallel
+computation for performance.
+
+*Child Stories (Implementation Steps):*
+* [DAPM-1234] Backend: Scenario Model & Persistence
+* [DAPM-1235] Frontend: Scenario Builder UI
+* [DAPM-1236] Backend: Delta Calculation Engine
+* [DAPM-1237] Frontend: Results Visualization
+
+---
+
+## Acceptance Criteria
+
+* **Verify** all child stories completed and deployed
+* **Verify** end-to-end scenario creation → delta calculation → visualization
+* **Verify** performance acceptable (delta calculation <2s for large scenarios)
+* **Verify** integration tests pass across all components
+* **Verify** documentation updated for scenario modeling
+```
+
+---
+
+## Section Details
+
+### H1 Title
+
+**Format:** Single markdown header at top of body (matches YAML title field)
+
+**Pattern:**
+- Stories/Tasks/Bugs: `# [Project]: [FE|BE|FS]: [Component]: [Feature]`
+- Epics: `# [Project]: [Component]: [Epic Theme]`
+
+**Examples:**
+```markdown
+# APM-R: FE: Dashboard: Configurable Cards
+# APM-R: BE: Data Layer: Subscription Support
+# APM-R: FS: Risk Engine: Scenario Analysis
+# APM-R: Infrastructure: Deployment: CI/CD Pipeline
+# APM-R: Risk Analytics: Scenario Analysis Engine (Epic)
+```
+
+**Rules:**
+- Matches YAML `title` field exactly
+- One line only
+- Descriptive and clear
+
+---
+
+### Section Divider: ---
+
+**Location:** After H1 title and between H2 sections
+
+**Purpose:** Visually separate sections in markdown (converted to Jira format on export)
+
+**Rules:**
+- Use exactly 3 hyphens: `---`
+- Must be on its own line
+- One blank line before and after (optional but recommended)
+
+**Example:**
+```markdown
+# Title
+
+---
+
+## Description
+```
+
+---
+
+### ## Description Section
+
+**Purpose:** Main ticket content (context, requirements, technical guidance)
+
+**Contains 3 subsections with BOLD labels (NOT ### headers):**
+
+#### 1. **Context:**
+
+**Purpose:** Explain WHY this ticket matters (business context and rationale)
+
+**Format:** 2-3 plain language paragraphs (NOT bullet points)
+
+**Rules:**
+- Write as natural paragraphs, not bullets
+- 3-5 sentences total
+- Explain the business problem or opportunity
+- Reference related tickets if relevant
+- Use plain language (not jargon)
+
+**Example:**
+```markdown
+**Context:**
+
+Polling is chatty, delayed, and harder to scale. We shaped the data layer to be
+subscription-ready; this story implements push updates for real-time status
+without altering page components.
+
+Users currently wait 5-10 seconds for updates. Real-time push reduces this to
+<100ms, dramatically improving user experience and reducing server load.
+
+Related ticket: [DAPM-1032](https://{your-org}.atlassian.net/browse/PROJ-1032)
+```
+
+**Anti-patterns:**
+```markdown
+❌ BAD - Bullet points in Context:
+**Context:**
+
+* Polling is inefficient
+* Delays are problematic
+* We need real-time updates
+[Wrong format - use paragraphs]
+
+❌ BAD - Too verbose:
+**Context:**
+
+In today's modern web applications, polling has been a longstanding approach...
+[5 more paragraphs explaining polling theory...]
+[Too long - keep to 3-5 sentences]
+```
+
+#### 2. **In Order to Support This:**
+
+**Purpose:** List what needs to be implemented (acceptance/completion criteria)
+
+**Format:** Bullet list with concise statements
+
+**Rules:**
+- Use `*` for bullets (NOT `-` or `+`)
+- Each bullet 1-2 sentences max
+- 4-6 top-level bullets
+- Max 2 nesting levels (sub-bullets under requirements)
+- Clear, specific language (not vague)
+
+**Example:**
+```markdown
+**In Order to Support This:**
+
+* Expose GraphQL subscription for status events (started/progress/completed/failed)
+* Switch data layer to subscription transport
+* Standardize connection: single active subscription per context, clean unsubscribe, reconnect with backoff
+* Enforce tenant isolation via org context from session/claims
+```
+
+**Anti-patterns:**
+```markdown
+❌ BAD - Too many bullets:
+**In Order to Support This:**
+
+* Implement subscriptions
+* Add error handling
+* Test on mobile
+* Test on tablet
+* Test on desktop
+* Add monitoring
+* Add alerting
+* Document the code
+* Write unit tests
+[Too many - consolidate]
+
+❌ BAD - Too much nesting:
+**In Order to Support This:**
+
+* Main requirement
+  * Sub-requirement
+    * Sub-sub-requirement
+      * Sub-sub-sub-requirement
+[Excessive nesting - max 2 levels]
+
+❌ BAD - Vague language:
+**In Order to Support This:**
+
+* Make it work
+* Improve performance
+* Handle errors
+[Not specific enough - be concrete]
+```
+
+#### 3. **Technical Notes:**
+
+**Purpose:** Implementation guidance (what patterns to follow, not HOW to implement)
+
+**Format:** Bullet list of high-level guidance
+
+**Rules:**
+- Use `*` for bullets
+- 3-5 bullets maximum
+- Reference PATTERNS, not step-by-step implementation
+- NO code snippets
+- High-level guidance only
+
+**Example:**
+```markdown
+**Technical Notes:**
+
+* Use Apollo Client subscriptions pattern (already established in codebase)
+* Performance target: <100ms latency for status updates
+* Coordinate with data team on subscription schema changes
+* Monitor WebSocket connection health
+```
+
+**Anti-patterns:**
+```markdown
+❌ BAD - Code snippets:
+**Technical Notes:**
+
+* Create a new class:
+  ```typescript
+  class SubscriptionManager {
+    constructor() { ... }
+    subscribe() { ... }
+  }
+  ```
+[Wrong - reference pattern, not code]
+
+❌ BAD - Step-by-step implementation:
+**Technical Notes:**
+
+* Step 1: Add Apollo Client dependency
+* Step 2: Create subscription query
+* Step 3: Add subscription hook
+* Step 4: Call hook in component
+[Wrong - tell what pattern, not how]
+
+❌ BAD - Too many bullets:
+**Technical Notes:**
+
+* Use pattern X
+* Handle error Y
+* Monitor metric Z
+* Log in format A
+* Add retry logic B
+* Configure timeout C
+* Test scenario D
+[Too many - consolidate to 3-5]
+```
+
+---
+
+### ## Acceptance Criteria Section
+
+**Purpose:** Specific, testable conditions that must be met for ticket completion
+
+**Format:** Bullet list with "Verify" statements
+
+**Rules:**
+- Use `*` for bullets (NOT `-`)
+- Start each with **Verify** (bold)
+- 8-12 bullets total
+- Specific and observable (not vague)
+- Cover: happy path + edge cases + errors + performance + documentation
+
+**Example:**
+```markdown
+## Acceptance Criteria
+
+* **Verify** users receive real-time status updates via push (not polling)
+* **Verify** GraphQL subscription includes all required event types
+* **Verify** single active subscription per context (no duplicates)
+* **Verify** unsubscribe cleanup prevents memory leaks
+* **Verify** reconnect logic with exponential backoff handles 3+ network failures
+* **Verify** tenant isolation enforced (user sees only their org's data)
+* **Verify** status update latency <100ms on 3G network
+* **Verify** works on iPhone 12, iPad Air, 1920px desktop
+* **Verify** error state shows user-friendly message on connection loss
+* **Verify** WebSocket connection health monitored and alerted
+* **Verify** integration tests cover happy path + edge cases
+* **Verify** documentation updated with subscription implementation pattern
+```
+
+**Coverage Checklist:**
+- ✅ Happy path (core functionality works)
+- ✅ Edge cases (empty data, large datasets, special conditions)
+- ✅ Error handling (network errors, invalid data, timeouts)
+- ✅ Performance (response time, resource usage)
+- ✅ Responsive design (desktop, tablet, mobile)
+- ✅ Monitoring/observability (logging, metrics, alerts)
+- ✅ Documentation (always included)
+
+**Anti-patterns:**
+```markdown
+❌ BAD - Vague criteria:
+* **Verify** it works
+* **Verify** performance is good
+* **Verify** errors are handled
+[Not specific/testable]
+
+❌ BAD - Implementation details:
+* **Verify** Apollo Client is used for subscriptions
+* **Verify** Redux store is updated
+* **Verify** database transaction is committed
+[Focus on behavior, not implementation]
+
+❌ BAD - Too few criteria:
+* **Verify** subscriptions work
+* **Verify** errors handled
+[Only 2 - need 8-12]
+```
+
+---
+
+## Special Cases
+
+### Out of Scope Section (Optional)
+
+**When to include:**
+- There's a specific feature/requirement users might expect but it's NOT included
+- There's a planned follow-up ticket for the excluded scope
+- Clarification is needed to prevent scope creep
+
+**When to OMIT:**
+- There's nothing specific to call out
+- Items are obviously unrelated to the story
+- You're struggling to think of items
+
+**Format:**
+```markdown
+### Out of Scope
+
+* Multi-user configuration sharing - Will be handled in DAPM-1450
+* Custom tile creation - Planned for Q2 2026 roadmap
+```
+
+**Rules:**
+- Only include if there's a specific reason
+- Keep brief (2-3 items max)
+- Reference follow-up tickets when deferring scope
+- OMIT this section entirely if nothing specific to call out
+
+---
+
+### Links in Body
+
+**Jira URLs (ALLOWED):**
+```markdown
+Related work: [DAPM-1032](https://{your-org}.atlassian.net/browse/PROJ-1032)
+Parent epic: [DAPM-1171](https://{your-org}.atlassian.net/browse/PROJ-1171)
+```
+
+**Framework files (NOT in body):**
+- Put cross-repo references in `framework-documentation` YAML field
+- Put local file references in `framework-relatedLocal` YAML field
+- Do NOT include file paths in the ticket body
+
+---
+
+## Formatting Rules Summary
+
+| Element | Rule |
+|---------|------|
+| H1 Title | Single line at top, matches YAML title |
+| Section dividers | `---` after H1 and between H2 sections |
+| H2 sections | Exactly 2: Description and Acceptance Criteria |
+| Subsection labels | Bold: `**Context:**`, `**In Order to Support This:**`, `**Technical Notes:**` |
+| Subsection headers | NO `###` headers - use bold labels only |
+| Context format | Plain paragraphs (NOT bullets) |
+| In Order to Support This format | Bullet list (NOT paragraphs) |
+| Technical Notes format | Bullet list (patterns only, no code) |
+| Acceptance Criteria format | Bullet list starting with **Verify** |
+| Code snippets | ZERO - reference patterns only |
+| Metadata in body | ZERO - all metadata in YAML frontmatter |
+| Line count | 30-100 lines (stories/tasks), 30-50 lines (epics) |
+
+---
+
+## Validation Checklist
+
+Before considering a ticket complete:
+
+- ✅ H1 title present and matches YAML title
+- ✅ Section dividers (`---`) present
+- ✅ Exactly 2 H2 sections: Description and Acceptance Criteria
+- ✅ NO `###` headers (use bold labels only)
+- ✅ Context as plain paragraphs (NOT bullets)
+- ✅ In Order to Support This as bullets (NOT paragraphs)
+- ✅ Technical Notes as bullets (NO code snippets)
+- ✅ 8-12 Acceptance Criteria starting with "Verify"
+- ✅ NO metadata lines in body (all in YAML)
+- ✅ Proper Jira URL format for cross-references
+- ✅ Total lines: 30-100 (stories/tasks) or 30-50 (epics)
+- ✅ Clear, concise language throughout