Enable jira issues to be provided in specification workflow

.spec/002-jira-integration/.spec-status.json

@@ -0,0 +1,3 @@
+{
+  "current-step": "Implementation Complete"
+}

.spec/002-jira-integration/api-integration-spec.yaml

@@ -0,0 +1,95 @@
+title: Jira REST API Integration Specification
+version: 1.0.0
+description: Technical specification for Jira REST API integration in specware CLI
+
+endpoint:
+  method: GET
+  path: "/rest/api/2/issue/{issueKey}"
+  base_url: "${JIRA_URL}"
+  timeout: 30s
+
+authentication:
+  type: personal_access_token
+  header: "Authorization"
+  format: "Bearer ${JIRA_API_TOKEN}"
+
+request:
+  headers:
+    Authorization: "Bearer ${JIRA_API_TOKEN}"
+    Accept: "application/json"
+    Content-Type: "application/json"
+  parameters:
+    issueKey:
+      type: string
+      pattern: "^[A-Za-z]+-[0-9]+$"
+      description: "Jira issue key format (e.g., PROJ-123 or proj-123)"
+
+response:
+  success:
+    status_code: 200
+    content_type: "application/json"
+    required_fields:
+      - key
+      - fields.summary
+      - fields.description
+      - fields.status.name
+      - fields.issuetype.name
+      - fields.priority.name
+      - fields.assignee.displayName
+    optional_fields:
+      - fields.assignee.emailAddress
+      - fields.reporter.displayName
+      - fields.created
+      - fields.updated
+
+error_responses:
+  authentication_failure:
+    status_code: 401
+    message: "Authentication failed. Check JIRA_API_TOKEN environment variable."
+    user_action: "Verify your personal access token has the correct permissions."
+
+  issue_not_found:
+    status_code: 404
+    message: "Issue '{issueKey}' not found."
+    user_action: "Verify the issue key exists and you have permission to view it."
+
+  permission_denied:
+    status_code: 403
+    message: "Access denied to issue '{issueKey}'."
+    user_action: "Verify you have permission to view this issue."
+
+  invalid_url:
+    status_code: null
+    message: "Invalid JIRA_URL format."
+    user_action: "Ensure JIRA_URL is a valid URL (e.g., https://company.atlassian.net)"
+
+  network_timeout:
+    status_code: null
+    message: "Network timeout after 30 seconds."
+    user_action: "Check network connectivity and Jira instance availability."
+
+  server_error:
+    status_code: 500
+    message: "Jira server error."
+    user_action: "Try again later or contact your Jira administrator."
+
+environment_variables:
+  JIRA_URL:
+    required: true
+    validation: non_empty_string
+    example: "https://company.atlassian.net"
+
+  JIRA_API_TOKEN:
+    required: true
+    validation: non_empty_string
+    sensitive: true
+    description: "Personal access token with issue read permissions"
+
+validation:
+  startup_checks:
+    - environment_variable_presence
+    - environment_variable_non_empty
+
+  runtime_checks:
+    - issue_key_format
+    - url_accessibility

.spec/002-jira-integration/context-implementation-plan.md

@@ -0,0 +1,70 @@
+# Context: Implementation Plan
+
+## Codebase Architecture Analysis
+
+### Project Structure
+- **Root structure**: Go module with Cobra CLI framework
+- **Command layer**: `cmd/` package with root.go registering subcommands
+- **Business logic**: `internal/spec/` package containing core functionality  
+- **Assets**: `assets/` package with embedded filesystem for templates, commands, agents
+- **Testing**: Ginkgo/Gomega BDD framework in `internal/spec/*_test.go`
+
+### Command Implementation Patterns
+- **Command definition**: Cobra commands in `cmd/` files with Use, Short, Long, Args, Run
+- **Function delegation**: Commands call `internal/spec` functions with error handling
+- **Error handling**: Commands print errors and call `os.Exit(1)` on failure
+- **File operations**: Functions return `([]string, error)` where strings are created file paths
+- **Status updates**: All commands follow pattern of status output then file listing
+
+### Testing Patterns
+- **Framework**: Ginkgo v2 with Gomega assertions in `spec_test` package
+- **Setup**: `BeforeEach`/`AfterEach` with temp directory creation/cleanup
+- **Tests**: Describe/It structure testing directory creation and file existence
+- **Assertions**: `Expect(err).NotTo(HaveOccurred())` and `Expect(path).To(BeADirectory())`
+
+### Existing Subcommand Structure
+- **Root command**: `specware` in `cmd/root.go:22-25` adds: initCmd, localizeTemplatesCmd, featureCmd
+- **Feature subcommands**: `cmd/feature.go:118-122` adds: newRequirementsCmd, newImplementationPlanCmd, updateStateCmd
+- **Pattern**: Each command calls internal/spec function, prints results, handles errors
+
+### Dependencies and Build
+- **Core deps**: cobra CLI, ginkgo/gomega testing, embed FS
+- **No HTTP libs**: Currently no HTTP client dependencies 
+- **Build**: Simple `go build -o specware .` and `go test ./...` commands
+- **Module**: Go 1.24.5 with standard semantic versioning
+
+### Code Style Observations
+- **Error messages**: Descriptive with context using fmt.Errorf
+- **Validation**: Input validation functions (ValidateFeatureName) with regex patterns
+- **File handling**: Standard os package operations with 0644/0755 permissions
+- **JSON**: Standard encoding/json for .spec-status.json files
+- **Package organization**: Clear separation between CLI layer and business logic
+
+## Questions & Answers
+Questions and provided answers
+
+### Q1: Should the new Jira command be added to the root command or as a subcommand under 'feature'?
+**Answer:** It should be added under a new sub-command `jira` like `specware jira get-issue`. This ensures scalability and seperates it from the feature commands and the core "project setup" commands at the root level.
+
+### Q2: Should we create a new file `cmd/jira.go` following the existing pattern?
+**Answer:** y
+
+### Q3: Should the HTTP client implementation be in the internal/spec package or a new internal/jira package?
+**Answer:** New internal jira package
+
+### Q4: Should we use Go's standard net/http package or add an external HTTP client dependency?
+**Answer:** You should review whether there is an official, well-documented, and often used golang SDK for jira. If that exists, we should prefer to use it. If it does not exist, standard packages are preferred.
+
+### Q5: Should the output formatting logic be a separate function in internal/spec package?
+**Answer:** It should be a seperate function in the internal/jira package
+
+### Testing Questions
+
+### Q6: Should we write unit tests for the HTTP client and formatting functions separately?
+**Answer:** Yes
+
+### Q7: Should we create integration tests that make actual HTTP calls to a test Jira instance?
+**Answer:** No, we should create integration tests that make calls to a mock jira instance.
+
+## Context Gathering Results
+Collection of any additional detail needed to inform requirements.

.spec/002-jira-integration/context-requirements.md

@@ -0,0 +1,70 @@
+# Context: Requirements
+
+## Questions & Answers
+Questions and provided answers
+
+### Q1: Will the Jira integration support fetching issues from multiple Jira instances?
+**Answer:** No
+
+### Q2: Should the Jira integration cache issue data locally to improve performance?
+**Answer:** No
+
+### Q3: Will users need to authenticate interactively or only use pre-configured tokens?
+**Answer:** Pre-configured
+
+### Q4: Should the integration support fetching related issues (linked issues, sub-tasks)?
+**Answer:** No
+
+### Q5: Will the Jira data need to be transformed or filtered before use in specifications?
+**Answer:** Yes, output should be formatted in a way Claude Code can understand - but the content should be unmodified.
+
+## Context Gathering Results
+Collection of any additional detail needed to inform requirements.
+
+### Codebase Architecture Analysis
+
+**Command Structure:**
+- Uses Cobra CLI framework (github.com/spf13/cobra)
+- Commands defined in `cmd/` package: root.go, feature.go, init.go, localize_templates.go
+- Root command structure in `cmd/root.go:22-25` adds subcommands: initCmd, localizeTemplatesCmd, featureCmd
+
+**Feature Command Pattern:**
+- Feature commands in `cmd/feature.go` follow pattern: featureCmd.AddCommand() in init()
+- Existing subcommands: new-requirements, new-implementation-plan, update-state
+- All commands use `spec` package functions: `spec.CreateNewRequirements()`, `spec.UpdateFeatureStatus()`
+
+**Internal Package Structure:**
+- Core logic in `internal/spec/spec.go` 
+- Functions follow pattern: validate input, handle filesystem operations, return created files list
+- Error handling: return error with context using fmt.Errorf()
+- File creation: uses os.WriteFile(), os.MkdirAll() with 0644/0755 permissions
+
+**No HTTP Client Patterns Found:**
+- Current codebase has no HTTP clients or external service integrations
+- No existing patterns for API authentication or JSON parsing for external services
+- Will need to add new dependencies for HTTP operations
+
+**Dependencies:**
+- Current: cobra CLI, ginkgo/gomega testing, embedded file system
+- Missing for Jira integration: HTTP client library, JSON unmarshaling for Jira responses
+
+**Testing Framework:**
+- Uses Ginkgo v2 and Gomega for BDD-style testing
+- Test files: `internal/spec/spec_test.go`, `internal/spec/spec_suite_test.go`
+
+### Expert Questions
+
+### Q6: Should the Jira integration validate environment variables at command startup?
+**Answer:** Yes, validation should be limited to the fact that they are a non-empty string and nothing more. Do not add complex validation.
+
+### Q7: Should the Jira issue data be output as structured JSON or formatted text?
+**Answer:** No
+
+### Q8: Should the integration support custom field extraction from Jira issues?
+**Answer:** No, avoid complexity we aren't certain we need.
+
+### Q9: Should network timeouts and retry logic be configurable?
+**Answer:** No
+
+### Q10: Should the command support outputting multiple issues in a single call?
+**Answer:** No