[Extension]: Add

### Extension ID

mainframe

### Extension Name

Mainframe Modernization (COBOL to Java)

### Version

1.0.1

### Description

Gated, evidence-driven COBOL-to-Java modernization: deterministic discovery, specification recovery with paragraph-level traceability, domain decomposition, target architecture, data modernization with a byte-level fidelity proof, forward engineering behind a specification firewall, and golden-master equivalence verification

### Author

Ankur Maan

### Repository URL

https://github.com/maanankur/spec-kit-mainframe

### Download URL

https://github.com/maanankur/spec-kit-mainframe/archive/refs/tags/v1.0.1.zip

### License

MIT

### Homepage (optional)

_No response_

### Documentation URL (optional)

https://github.com/maanankur/spec-kit-mainframe/blob/main/README.md

### Changelog URL (optional)

https://github.com/maanankur/spec-kit-mainframe/blob/main/CHANGELOG.md

### Required Spec Kit Version

>=0.1.0

### Required Tools (optional)

```markdown
python >=3.10 (required), docker >=24.0 (optional — legacy GnuCOBOL harness and the compose stack)
```

### Number of Commands

12

### Number of Hooks (optional)

4

### Tags

python >=3.10 (required), docker >=24.0 (optional — legacy GnuCOBOL harness and the compose stack)

### Key Features

- Deterministic discovery: inventory, dependency graph, CRUD matrix, copybook field maps from the raw COBOL/JCL/copybooks
- Specification recovery with mandatory paragraph-level traceability (100% gate) and sourced business rules
- Domain decomposition and target-architecture scoring with a visible, computed wave plan
- Data modernization with a byte-level round-trip fidelity proof (decode -> re-encode -> compare) before any schema is trusted
- Forward engineering behind a specification firewall: generated code has no read path to the legacy source
- Golden-master equivalence: runs the real COBOL under GnuCOBOL and compares field-by-field against the generated Java
- 7 hash-bound gates (G1-G7); a red evidence row can only be waived (owner, control, expiry), never approved
- Optional --auto-approve for unattended runs, still fully evidenced and audited

### Testing Checklist

- [x] Extension installs successfully via download URL
- [x] All commands execute without errors
- [x] Documentation is complete and accurate
- [x] No security vulnerabilities identified
- [x] Tested on at least one real project

### Submission Requirements

- [x] Valid `extension.yml` manifest included
- [x] README.md with installation and usage instructions
- [x] LICENSE file included
- [x] GitHub release created with version tag
- [x] All command files exist and are properly formatted
- [x] Extension ID follows naming conventions (lowercase-with-hyphens)

### Testing Details

Installed via `specify extension add --dev` locally, and via `specify extension add mainframe --from ` in a fresh Spec Kit project (non-interactive confirm). All 12 commands render into both `.claude/commands` and `.claude/skills` depending on target project layout; the `modernize`/`assess`/`gate_decide`/`verify_source_readonly` tools were run end-to-end through both the bash and PowerShell wrapper entry points. Exercised against a real legacy application: AWS CardDemo (44 COBOL programs, 870 paragraphs) - two full runs with the source Claude Code plugin (440 business rules traced at 100%, 11 bounded contexts, a Spring Boot 3 + React application built and deployed under Docker Compose, the COBOL batch chain executed under GnuCOBOL, golden-master comparison with 0 unexplained differences on sample data), then repackaged and re-verified as this extension. No secrets, credentials or telemetry in the extension; the legacy source tree is verified read-only by hash before every gate (`verify_source_readonly.py`). Environment: Windows 11, Git Bash, Python 3.12, specify-cli 0.16.2, Docker for the harness.

### Example Usage

```markdown
specify init my-project --integration claude
cd my-project
specify extension add mainframe --from https://github.com/maanankur/spec-kit-mainframe/archive/refs/tags/v1.0.1.zip

# from inside the Spec Kit project - source can live anywhere, workspace lands here
/speckit.mainframe.modernize /path/to/cobol-app
/speckit.mainframe.spec # phase 2 -> Gate G1
/speckit.mainframe.gate --gate G1 --decision approved-with-conditions --by alice@x --condition "C1 ..."
/speckit.mainframe.status
```

### Proposed Catalog Entry

```json
{
"name": "Mainframe Modernization (COBOL to Java)",
"id": "mainframe",
"description": "Gated, evidence-driven COBOL-to-Java modernization: deterministic discovery, specification recovery with paragraph-level traceability, domain decomposition, target architecture, data modernization with a byte-level fidelity proof, forward engineering behind a specification firewall, and golden-master equivalence verification",
"author": "Ankur Maan",
"version": "1.0.1",
"download_url": "https://github.com/maanankur/spec-kit-mainframe/archive/refs/tags/v1.0.1.zip",
"repository": "https://github.com/maanankur/spec-kit-mainframe",
"documentation": "https://github.com/maanankur/spec-kit-mainframe/blob/main/README.md",
"changelog": "https://github.com/maanankur/spec-kit-mainframe/blob/main/CHANGELOG.md",
"license": "MIT",
"category": "modernization",
"effect": "read-write",
"requires": {
"speckit_version": ">=0.1.0",
"tools": [
{"name": "python", "required": true, "version": ">=3.10"},
{"name": "docker", "required": false, "version": ">=24.0"}
]
},
"provides": {"commands": 12, "hooks": 4},
"tags": ["cobol", "mainframe", "legacy-modernization", "java", "spring-boot"],
"verified": false,
"downloads": 0,
"stars": 0,
"created_at": "2026-09-11T00:00:00Z",
"updated_at": "2026-09-11T00:00:00Z"
}
```

### Additional Context

Packaged from a Claude Code plugin (AgenticModernizationFramework/mainframe-modernization) that was developed and exercised over two end-to-end runs against AWS CardDemo before being converted to a Spec Kit extension. docs/STATUS.md and docs/LIMITATIONS.md in the repo are candid about what is implemented versus still scaffolding (e.g. most technique skills and MCP integrations are placeholders; the deterministic pipeline, gates and golden-master verification are fully working).

Inspect the submitted extension.yml, README.md, and docs/STATUS.md and docs/LIMITATIONS.md in the linked repository first. Compare the proposed catalog entry with the repository’s extension requirements, then verify the installation, commands, hooks, and documented limitations; done means the extension is accepted with accurate catalog metadata and reproducible checks.

Written by the indexing model from the issue text.