@codewalla_india/openspec 1.0.5 → 1.0.6

package/dist/core/templates/workflows/mcp-guidance.d.ts

@@ -6,7 +6,7 @@
  * and Playwright MCP tools.
  */
 export declare const ATLASSIAN_ENRICHMENT_GUIDANCE = "3.5. **Enrich from Jira (if ticket key available)**\n\n   Scan the change name, proposal.md, and design.md for a Jira issue key\n   (pattern: one or more capital letters, a dash, one or more digits \u2014 e.g., CW-123, PROJ-456).\n\n   If a ticket key is found, use the **Atlassian MCP**:\n\n   **a. Fetch the issue**\n   - Retrieve: summary, description, issue type, status, labels\n   - Extract any \"Acceptance Criteria\" section from the description\n   - Note the assignee and reporter\n\n   **b. Walk the parent hierarchy**\n   - If the issue has a parent (sub-task \u2192 story, or story \u2192 epic):\n     - Fetch the parent ticket for business goal context\n     - If parent has a parent (epic), fetch that too for initiative framing\n     - Note the full path: Initiative \u2192 Epic \u2192 Story \u2192 Sub-task\n\n   **c. Fetch recent comments**\n   - Get comments, ordered by date\n   - Look for scope reduction (\"out of scope\", \"defer X\"), changed approach,\n     blocker resolutions, or QA/review feedback added after planning\n\n   **d. Cross-check against tasks.md**\n   - For each acceptance criterion in Jira: verify at least one task covers it\n   - If an AC has no corresponding task \u2192 add it to the flagged list\n   - For any comment that changed scope post-planning \u2192 note the discrepancy\n\n   **Output:** Print a \"Jira Context\" section showing:\n   - Ticket key + summary, type, status\n   - Parent chain (if any)\n   - ACs: covered \u2713 / not covered \u2717\n   - Scope-change comments (if any, with date)\n   - \"Proceeding with implementation\" or \"\u26A0 Pausing \u2014 scope mismatch found, confirm before continuing\"\n\n   **If no ticket key found or Atlassian MCP unavailable:** Skip silently and continue.";
-export declare const ATLASSIAN_PROPOSE_GUIDANCE = "0. **Import from Jira (if a ticket key is provided)**\n\n   If the user's input contains or is a Jira issue key (e.g., \"CW-1234\" or \"CW-1234 add dark mode\"):\n\n   Use the **Atlassian MCP** to fetch the issue:\n   - summary \u2192 becomes the change name candidate (kebab-case it)\n   - description \u2192 seed for proposal.md \"Why\" and \"What Changes\" sections\n   - acceptance criteria \u2192 seed for specs artifact requirements\n   - parent epic \u2192 context for the \"Impact\" section of the proposal\n\n   Walk the parent chain:\n   - Fetch the epic (or story parent) for business-level framing\n   - Include the epic goal as opening context in the proposal\n\n   After fetching, proceed to step 1 using the ticket data as pre-filled input.\n   Tell the user: \"Found CW-1234: '<summary>'. Creating change from Jira ticket.\"\n\n   **If no ticket key:** proceed normally from step 1.";
+export declare const ATLASSIAN_PROPOSE_GUIDANCE = "0. **Import from Jira (if a ticket key is provided)**\n\n   If the user's input contains or is a Jira issue key (e.g., \"CW-1234\" or \"CW-1234 add dark mode\"):\n\n   Use the **Atlassian MCP** to fetch the issue:\n   - summary \u2192 becomes the change name candidate (kebab-case it)\n   - description \u2192 seed for proposal.md \"Why\" and \"What Changes\" sections\n   - acceptance criteria \u2192 seed for specs artifact requirements\n   - parent epic \u2192 context for the \"Impact\" section of the proposal\n\n   Walk the parent chain:\n   - Fetch the epic (or story parent) for business-level framing\n   - Include the epic goal as opening context in the proposal\n\n   After fetching, proceed to step 1 using the ticket data as pre-filled input.\n   Tell the user: \"Found CW-1234: '<summary>'. Creating change from Jira ticket.\"\n\n   **Naming conventions** (Jira tracks work; specs track behavior):\n\n   - **Change name**: kebab-case summary; optionally prefix with lowercase ticket key\n     (e.g., `cw-1234-add-dark-mode`). Never use the ticket key alone as the change name.\n   - **Capabilities** (proposal + delta specs): pick domain names from existing\n     `openspec/specs/` or derive from behavior (`ui`, `auth`). **Do NOT** name\n     capabilities or spec folders after the Jira key.\n   - **Acceptance criteria**: map each AC to requirements/scenarios inside the\n     appropriate capability spec\u2014not to a ticket-named spec file.\n   - **Traceability**: record ticket key(s) in proposal **Impact**\n     (e.g., `Jira: CW-1234` or `Jira: CW-100 (epic), CW-1234 (story)`).\n   - **Follow-up work**: when continuing or splitting ticket work, create a new change\n     folder with a distinct name; reference the same or related tickets in Impact.\n     Do not reuse archived change folders or ticket-key spec folders.\n\n   **If no ticket key:** proceed normally from step 1.";
 export declare const CONTEXT7_LOOKUP_GUIDANCE = "   **Before implementing each task \u2014 library check:**\n\n   If the task description references a specific library, framework, or package\n   (e.g., \"implement with Prisma\", \"add React Query cache\", \"use Drizzle ORM transactions\",\n   \"migrate to Next.js App Router\", \"use tRPC v11 procedure\"):\n\n   1. Call `resolve-library-id` (Context7 MCP) with the library name to get its Context7 ID\n   2. Call `query-docs` with the Context7 ID and the specific question from the task\n      \u2014 e.g., \"How to use transactions with Drizzle ORM 0.38?\"\n   3. Use the returned documentation to guide the implementation\n\n   **When to trigger this check:**\n   - Task mentions a package by name\n   - Task uses version-specific language (\"v5 API\", \"new hook syntax\")\n   - Task involves migration between library versions\n   - The codebase's package.json shows a recently updated dependency relevant to the task\n\n   **When to skip:**\n   - Task is purely business logic (no library API involved)\n   - You already fetched docs for this library in a previous task this session\n     (reuse the earlier result, don't call again)\n\n   **Cap:** Do not call Context7 more than 3 times per apply session.";
 export declare const PLAYWRIGHT_APPLY_GUARDRAIL = "- Do NOT run Playwright or browser tests during apply. If the user explicitly asks to also \"run tests\", \"verify UI\", or \"check in browser\" in the same message, complete all tasks first, then invoke openspec-verify-change (or `/opsx:verify`) to handle browser verification \u2014 do not do it inline during apply";
 export declare const PLAYWRIGHT_VERIFY_GUIDANCE = "8. **Browser verification (Playwright)**\n\n   After codebase analysis (steps 5\u20137), assess if the change touches UI or web pages:\n   - proposal.md or tasks.md mentions pages, components, screens, UI, CSS, visual, layout\n\n   **If yes, use the Playwright MCP:**\n\n   **a. Check for a running dev server**\n   - Scan package.json `scripts` for: `dev`, `start`, `preview`, `serve`\n   - Check if localhost is reachable (common ports: 3000, 3001, 5173, 8080)\n   - If a URL is available, announce it. If not, note \"No dev server detected \u2014 skipping visual verification.\"\n\n   **b. If dev server is reachable:**\n   - Use `browser_navigate` to open the affected page(s) identified from the change\n   - Use `browser_take_screenshot` to capture the current visual state\n   - Use `browser_snapshot` to get the accessibility tree and verify key elements\n   - Use `browser_console_messages` to check for JS errors introduced by this change\n   - If network requests are relevant: `browser_network_requests` to spot regressions\n\n   **c. Playwright test files**\n   Search the project for:\n   - `**/*.spec.ts`, `**/*.e2e.ts`, `**/playwright/**/*.ts`, `**/e2e/**/*.ts`\n   If test files related to the changed pages/components are found:\n   - List them\n   - If the user asks you to run them, execute and report pass/fail inline\n\n   **If no dev server is reachable:**\n   Add a SUGGESTION to the report: \"Start dev server and re-run /opsx:verify for visual confirmation.\"\n\n   Include browser results in the verification report (step 9).";

package/dist/core/templates/workflows/mcp-guidance.js

@@ -58,6 +58,21 @@ export const ATLASSIAN_PROPOSE_GUIDANCE = `0. **Import from Jira (if a ticket ke
    After fetching, proceed to step 1 using the ticket data as pre-filled input.
    Tell the user: "Found CW-1234: '<summary>'. Creating change from Jira ticket."
 
+   **Naming conventions** (Jira tracks work; specs track behavior):
+
+   - **Change name**: kebab-case summary; optionally prefix with lowercase ticket key
+     (e.g., \`cw-1234-add-dark-mode\`). Never use the ticket key alone as the change name.
+   - **Capabilities** (proposal + delta specs): pick domain names from existing
+     \`openspec/specs/\` or derive from behavior (\`ui\`, \`auth\`). **Do NOT** name
+     capabilities or spec folders after the Jira key.
+   - **Acceptance criteria**: map each AC to requirements/scenarios inside the
+     appropriate capability spec—not to a ticket-named spec file.
+   - **Traceability**: record ticket key(s) in proposal **Impact**
+     (e.g., \`Jira: CW-1234\` or \`Jira: CW-100 (epic), CW-1234 (story)\`).
+   - **Follow-up work**: when continuing or splitting ticket work, create a new change
+     folder with a distinct name; reference the same or related tickets in Impact.
+     Do not reuse archived change folders or ticket-key spec folders.
+
    **If no ticket key:** proceed normally from step 1.`;
 export const CONTEXT7_LOOKUP_GUIDANCE = `   **Before implementing each task — library check:**
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@codewalla_india/openspec",
-  "version": "1.0.05",
+  "version": "1.0.6",
   "description": "AI-native system for spec-driven development",
   "keywords": [
     "openspec",

package/schemas/spec-driven/schema.yaml

@@ -15,7 +15,12 @@ artifacts:
       - **Capabilities**: Identify which specs will be created or modified:
         - **New Capabilities**: List capabilities being introduced. Each becomes a new `specs/<name>/spec.md`. Use kebab-case names (e.g., `user-auth`, `data-export`).
         - **Modified Capabilities**: List existing capabilities whose REQUIREMENTS are changing. Only include if spec-level behavior changes (not just implementation details). Each needs a delta spec file. Check `openspec/specs/` for existing spec names. Leave empty if no requirement changes.
-      - **Impact**: Affected code, APIs, dependencies, or systems.
+      - **Impact**: Affected code, APIs, dependencies, or systems. If importing from
+        Jira, record ticket key(s) here (e.g., `Jira: CW-1234`) for traceability.
+
+      When importing from Jira: name capabilities by behavioral domain (e.g., `ui`,
+      `user-auth`), not by ticket key. Reference the ticket in Impact, not in
+      capability names.
 
       IMPORTANT: The Capabilities section is critical. It creates the contract between
       proposal and specs phases. Research existing specs before filling this in.
@@ -38,6 +43,9 @@ artifacts:
       - New capabilities: use the exact kebab-case name from the proposal (specs/<capability>/spec.md).
       - Modified capabilities: use the existing spec folder name from openspec/specs/<capability>/ when creating the delta spec at specs/<capability>/spec.md.
 
+      When Jira acceptance criteria exist: translate them into requirements under the
+      capability folders listed in the proposal. Never create specs/<ticket-key>/.
+
       Delta operations (use ## headers):
       - **ADDED Requirements**: New capabilities
       - **MODIFIED Requirements**: Changed behavior - MUST include full updated content

package/schemas/spec-driven/templates/proposal.md

@@ -21,3 +21,4 @@
 ## Impact
 
 <!-- Affected code, APIs, dependencies, systems -->
+<!-- If this change maps to a Jira ticket, note it here (e.g., Jira: CW-1234). Do NOT use the ticket key as a capability name. -->