normattiva2md 2.0.19__tar.gz

normattiva2md-2.0.19/.claude/CLAUDE.md

@@ -0,0 +1,129 @@
+# CLAUDE.md
+
+This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
+
+## Project Overview
+
+**Akoma2MD** is a CLI tool that converts XML documents in Akoma Ntoso format (legal documents from normattiva.it) to readable Markdown. The tool is designed to produce LLM-friendly output for building legal AI bots.
+
+## Core Architecture
+
+### Main Components
+
+- `convert_akomantoso.py`: Unified CLI tool (requires `requests`)
+  - Entry point: `main()` function with auto-detect URL/file
+  - URL support: `is_normattiva_url()`, `extract_params_from_normattiva_url()`, `download_akoma_ntoso()`
+  - Core conversion: `convert_akomantoso_to_markdown_improved(xml_path, md_path=None)` - outputs to stdout if md_path is None
+  - Text extraction: `clean_text_content(element)` handles inline formatting, refs, and modifications
+  - Article processing: `process_article(article_element, markdown_list, ns)` handles paragraphs and lists
+  - Status messages: routed to stderr when outputting markdown to stdout
+
+- `fetch_normattiva.py`: Alternative fetcher (requires `tulit` library)
+  - Downloads documents from normattiva.it API
+  - Requires specific parameters (not URL-based)
+  - Converts to Markdown or JSON
+  - Entry point: `main()` with argparse CLI
+
+- `setup.py`: Package configuration for PyPI distribution
+
+### XML Processing
+
+The converter handles Akoma Ntoso 3.0 namespace: `http://docs.oasis-open.org/legaldocml/ns/akn/3.0`
+
+Document structure extraction:
+
+- Title: `//akn:docTitle`
+- Preamble: `//akn:preamble`
+- Body: `//akn:body` → chapters → sections → articles → paragraphs → lists
+- Articles: `//akn:article` with `akn:num` (number) and `akn:heading` (title)
+- Legislative modifications: wrapped in `(( ))` from `<ins>` and `<del>` tags
+
+## Common Development Tasks
+
+### Running the converter (auto-detect URL/file)
+
+```bash
+# Output to file
+python convert_akomantoso.py input.xml output.md
+akoma2md input.xml output.md
+
+# Output to stdout (default when -o omitted)
+python convert_akomantoso.py input.xml
+akoma2md input.xml > output.md
+akoma2md -i input.xml
+
+# From normattiva.it URL (auto-detected)
+python convert_akomantoso.py "https://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:legge:2022;53" output.md
+akoma2md "URL" > output.md
+akoma2md -i "URL" -o output.md
+
+# With named arguments
+akoma2md -i input.xml -o output.md
+
+# Keep temporary XML from URL
+akoma2md "URL" output.md --keep-xml
+akoma2md "URL" --keep-xml > output.md
+```
+
+### Alternative: Fetching with specific parameters
+
+```bash
+# Requires: pip install tulit
+python fetch_normattiva.py --dataGU YYYYMMDD --codiceRedaz CODE --dataVigenza YYYYMMDD --output file.md --format markdown
+```
+
+### Testing
+
+```bash
+# Basic test with sample data
+python convert_akomantoso.py test_data/20050516_005G0104_VIGENZA_20250130.xml test_output.md
+```
+
+### Building executable
+
+```bash
+pip install pyinstaller
+pyinstaller --onefile --name akoma2md convert_akomantoso.py
+```
+
+### Package installation
+
+```bash
+# CLI tool installation (recommended)
+uv tool install .
+
+# Development mode (requires venv)
+pip install -e .
+
+# From source (requires venv)
+pip install .
+```
+
+## Key Design Decisions
+
+### Markdown Output Format
+
+- Articles: `# Art. X - Title`
+- Chapters: `## Chapter Title`
+- Sections: `### Section Title`
+- Numbered paragraphs: `1. Text content`
+- Lists: Markdown bullet lists with `- a) item text`
+- Legislative changes: Wrapped in `((modified text))`
+
+### Text Cleaning
+
+- Removes excessive whitespace and indentation
+- Preserves inline formatting (bold, emphasis)
+- Extracts text from `<ref>` tags
+- Prevents double-wrapping of `(( ))` in modifications
+- Filters out horizontal separator lines (`----`)
+
+## Project Constraints
+
+- **Minimal dependencies**: only `requests` for URL fetching
+- Python 3.7+ compatibility
+- CLI must support both positional and named arguments
+- Auto-detect URL vs file input
+- Output defaults to stdout when not specified (file optional)
+- Status messages always go to stderr to keep stdout clean for piping
+- Output must be LLM-friendly Markdown

normattiva2md-2.0.19/.claude/commands/openspec/apply.md

@@ -0,0 +1,23 @@
+---
+name: OpenSpec: Apply
+description: Implement an approved OpenSpec change and keep tasks in sync.
+category: OpenSpec
+tags: [openspec, apply]
+---
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+
+**Steps**
+Track these steps as TODOs and complete them one by one.
+1. Read `changes/<id>/proposal.md`, `design.md` (if present), and `tasks.md` to confirm scope and acceptance criteria.
+2. Work through tasks sequentially, keeping edits minimal and focused on the requested change.
+3. Confirm completion before updating statuses—make sure every item in `tasks.md` is finished.
+4. Update the checklist after all work is done so each task is marked `- [x]` and reflects reality.
+5. Reference `openspec list` or `openspec show <item>` when additional context is required.
+
+**Reference**
+- Use `openspec show <id> --json --deltas-only` if you need additional context from the proposal while implementing.
+<!-- OPENSPEC:END -->

normattiva2md-2.0.19/.claude/commands/openspec/archive.md

@@ -0,0 +1,27 @@
+---
+name: OpenSpec: Archive
+description: Archive a deployed OpenSpec change and update specs.
+category: OpenSpec
+tags: [openspec, archive]
+---
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+
+**Steps**
+1. Determine the change ID to archive:
+   - If this prompt already includes a specific change ID (for example inside a `<ChangeId>` block populated by slash-command arguments), use that value after trimming whitespace.
+   - If the conversation references a change loosely (for example by title or summary), run `openspec list` to surface likely IDs, share the relevant candidates, and confirm which one the user intends.
+   - Otherwise, review the conversation, run `openspec list`, and ask the user which change to archive; wait for a confirmed change ID before proceeding.
+   - If you still cannot identify a single change ID, stop and tell the user you cannot archive anything yet.
+2. Validate the change ID by running `openspec list` (or `openspec show <id>`) and stop if the change is missing, already archived, or otherwise not ready to archive.
+3. Run `openspec archive <id> --yes` so the CLI moves the change and applies spec updates without prompts (use `--skip-specs` only for tooling-only work).
+4. Review the command output to confirm the target specs were updated and the change landed in `changes/archive/`.
+5. Validate with `openspec validate --strict` and inspect with `openspec show <id>` if anything looks off.
+
+**Reference**
+- Use `openspec list` to confirm change IDs before archiving.
+- Inspect refreshed specs with `openspec list --specs` and address any validation issues before handing off.
+<!-- OPENSPEC:END -->

normattiva2md-2.0.19/.claude/commands/openspec/proposal.md

@@ -0,0 +1,27 @@
+---
+name: OpenSpec: Proposal
+description: Scaffold a new OpenSpec change and validate strictly.
+category: OpenSpec
+tags: [openspec, change]
+---
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.
+
+**Steps**
+1. Review `openspec/project.md`, run `openspec list` and `openspec list --specs`, and inspect related code or docs (e.g., via `rg`/`ls`) to ground the proposal in current behaviour; note any gaps that require clarification.
+2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, and `design.md` (when needed) under `openspec/changes/<id>/`.
+3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
+4. Capture architectural reasoning in `design.md` when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs.
+5. Draft spec deltas in `changes/<id>/specs/<capability>/spec.md` (one folder per capability) using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement and cross-reference related capabilities when relevant.
+6. Draft `tasks.md` as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work.
+7. Validate with `openspec validate <id> --strict` and resolve every issue before sharing the proposal.
+
+**Reference**
+- Use `openspec show <id> --json --deltas-only` or `openspec show <spec> --type spec` to inspect details when validation fails.
+- Search existing requirements with `rg -n "Requirement:|Scenario:" openspec/specs` before writing new ones.
+- Explore the codebase with `rg <keyword>`, `ls`, or direct file reads so proposals align with current implementation realities.
+<!-- OPENSPEC:END -->

normattiva2md-2.0.19/.gemini/GEMINI.md

@@ -0,0 +1,57 @@
+# Metodologia di Lavoro con Gemini CLI
+
+Questo documento descrive la metodologia di lavoro adottata durante l'interazione con l'agente Gemini CLI per lo sviluppo del progetto `normattiva_2_md`.
+
+## 1. Agente CLI Interattivo
+
+L'interazione avviene tramite un'interfaccia a riga di comando, dove l'agente risponde a richieste specifiche, esegue operazioni e fornisce feedback in tempo reale.
+
+## 2. Workflow Orientato al Task
+
+Il processo di sviluppo segue un ciclo iterativo:
+
+- Comprensione: L'agente analizza la richiesta dell'utente e il contesto del progetto (file esistenti, obiettivi).
+
+- Pianificazione: Viene formulato un piano conciso per affrontare il task, spesso includendo l'uso di strumenti specifici.
+
+- Implementazione: L'agente esegue le azioni pianificate utilizzando gli strumenti disponibili (operazioni su file, comandi shell, interazioni Git).
+
+- Verifica: I risultati vengono verificati, spesso con il feedback diretto dell'utente o tramite l'analisi dell'output generato.
+
+- Iterazione/Raffinamento: Sulla base della verifica, il processo si ripete per affinare la soluzione o affrontare nuovi task.
+
+## 3. Utilizzo degli Strumenti
+
+L'agente utilizza una suite di strumenti per interagire con il filesystem, eseguire comandi shell, e gestire il controllo versione:
+
+- Operazioni su File: Lettura, scrittura, modifica e ridenominazione di file (`read_file`, `write_file`, `replace`, `mv`).
+
+- Comandi Shell: Esecuzione di comandi di sistema (`run_shell_command`) per operazioni come la creazione di directory, la rimozione di file, o l'interazione con Git.
+
+- Operazioni Git: Gestione del repository (`git init`, `git add`, `git commit`, `git push`, `git status`, `git log`).
+
+- Web Fetching: Recupero di contenuti da URL (`web_fetch`) per analisi o download (es. `tulit` per Normattiva).
+
+## 4. Collaborazione con l'Utente
+
+La collaborazione è un aspetto centrale. L'agente si basa sulle istruzioni esplicite dell'utente e sul feedback per guidare lo sviluppo. Le decisioni chiave e i cambiamenti di strategia vengono discussi e approvati dall'utente.
+
+## 5. Specificità e Adattabilità
+
+L'agente si adatta alle esigenze specifiche del progetto, come dimostrato dalla capacità di:
+
+- Rifinire la qualità dell'output Markdown basandosi su requisiti dettagliati (es. gestione delle righe vuote, filtraggio del testo abrogato).
+
+- Modificare la pipeline di elaborazione (es. passaggio da XML diretto a JSON intermedio e poi ritorno a XML diretto) per ottimizzare i risultati.
+
+## 6. Documentazione del Progetto
+
+Durante lo sviluppo, viene mantenuta una documentazione aggiornata per tracciare i progressi e le decisioni:
+
+- `LOG.md`: Registro cronologico degli avanzamenti e delle modifiche significative. **Nota: I log dovrebbero essere concisi, focalizzandosi sui punti chiave e sulle decisioni, evitando dettagli eccessivi.**
+
+- `README.md`: Descrizione generale del progetto, istruzioni di installazione e utilizzo.
+
+- `PRD.md`: Documento dei requisiti di prodotto, che evolve con la comprensione degli obiettivi.
+
+- `VERIFICATION.md`: Checklist e stato verifiche qualità output Markdown.

normattiva2md-2.0.19/.gitattributes

@@ -0,0 +1,7 @@
+# Imposta i fine riga per i file di testo
+*.py text eol=lf
+*.md text eol=lf
+*.xml text eol=lf
+
+# Normalizza i fine riga per tutti i file di testo
+* text=auto

normattiva2md-2.0.19/.github/prompts/openspec-apply.prompt.md

@@ -0,0 +1,22 @@
+---
+description: Implement an approved OpenSpec change and keep tasks in sync.
+---
+
+$ARGUMENTS
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+
+**Steps**
+Track these steps as TODOs and complete them one by one.
+1. Read `changes/<id>/proposal.md`, `design.md` (if present), and `tasks.md` to confirm scope and acceptance criteria.
+2. Work through tasks sequentially, keeping edits minimal and focused on the requested change.
+3. Confirm completion before updating statuses—make sure every item in `tasks.md` is finished.
+4. Update the checklist after all work is done so each task is marked `- [x]` and reflects reality.
+5. Reference `openspec list` or `openspec show <item>` when additional context is required.
+
+**Reference**
+- Use `openspec show <id> --json --deltas-only` if you need additional context from the proposal while implementing.
+<!-- OPENSPEC:END -->

normattiva2md-2.0.19/.github/prompts/openspec-archive.prompt.md

@@ -0,0 +1,26 @@
+---
+description: Archive a deployed OpenSpec change and update specs.
+---
+
+$ARGUMENTS
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+
+**Steps**
+1. Determine the change ID to archive:
+   - If this prompt already includes a specific change ID (for example inside a `<ChangeId>` block populated by slash-command arguments), use that value after trimming whitespace.
+   - If the conversation references a change loosely (for example by title or summary), run `openspec list` to surface likely IDs, share the relevant candidates, and confirm which one the user intends.
+   - Otherwise, review the conversation, run `openspec list`, and ask the user which change to archive; wait for a confirmed change ID before proceeding.
+   - If you still cannot identify a single change ID, stop and tell the user you cannot archive anything yet.
+2. Validate the change ID by running `openspec list` (or `openspec show <id>`) and stop if the change is missing, already archived, or otherwise not ready to archive.
+3. Run `openspec archive <id> --yes` so the CLI moves the change and applies spec updates without prompts (use `--skip-specs` only for tooling-only work).
+4. Review the command output to confirm the target specs were updated and the change landed in `changes/archive/`.
+5. Validate with `openspec validate --strict` and inspect with `openspec show <id>` if anything looks off.
+
+**Reference**
+- Use `openspec list` to confirm change IDs before archiving.
+- Inspect refreshed specs with `openspec list --specs` and address any validation issues before handing off.
+<!-- OPENSPEC:END -->

normattiva2md-2.0.19/.github/prompts/openspec-proposal.prompt.md

@@ -0,0 +1,26 @@
+---
+description: Scaffold a new OpenSpec change and validate strictly.
+---
+
+$ARGUMENTS
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.
+
+**Steps**
+1. Review `openspec/project.md`, run `openspec list` and `openspec list --specs`, and inspect related code or docs (e.g., via `rg`/`ls`) to ground the proposal in current behaviour; note any gaps that require clarification.
+2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, and `design.md` (when needed) under `openspec/changes/<id>/`.
+3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
+4. Capture architectural reasoning in `design.md` when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs.
+5. Draft spec deltas in `changes/<id>/specs/<capability>/spec.md` (one folder per capability) using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement and cross-reference related capabilities when relevant.
+6. Draft `tasks.md` as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work.
+7. Validate with `openspec validate <id> --strict` and resolve every issue before sharing the proposal.
+
+**Reference**
+- Use `openspec show <id> --json --deltas-only` or `openspec show <spec> --type spec` to inspect details when validation fails.
+- Search existing requirements with `rg -n "Requirement:|Scenario:" openspec/specs` before writing new ones.
+- Explore the codebase with `rg <keyword>`, `ls`, or direct file reads so proposals align with current implementation realities.
+<!-- OPENSPEC:END -->

normattiva2md-2.0.19/.github/workflows/jekyll.yml

@@ -0,0 +1,56 @@
+name: Deploy Jekyll site to Pages
+
+on:
+  push:
+    branches: ["main"]
+  workflow_dispatch:
+
+permissions:
+  contents: read
+  pages: write
+  id-token: write
+
+concurrency:
+  group: "pages"
+  cancel-in-progress: false
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Setup Ruby
+        uses: ruby/setup-ruby@v1
+        with:
+          ruby-version: '3.3'
+          bundler-cache: true
+          cache-version: 0
+          working-directory: docs
+
+      - name: Setup Pages
+        id: pages
+        uses: actions/configure-pages@v5
+
+      - name: Build with Jekyll
+        run: bundle exec jekyll build --baseurl "${{ steps.pages.outputs.base_path }}"
+        working-directory: docs
+        env:
+          JEKYLL_ENV: production
+
+      - name: Upload artifact
+        uses: actions/upload-pages-artifact@v3
+        with:
+          path: docs/_site
+
+  deploy:
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    runs-on: ubuntu-latest
+    needs: build
+    steps:
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@v4

normattiva2md-2.0.19/.github/workflows/release-binaries.yml

@@ -0,0 +1,146 @@
+name: Build Releases
+
+on:
+  workflow_dispatch: {}
+  push:
+    tags:
+      - "v*"
+
+permissions:
+  contents: read
+
+jobs:
+  build-linux:
+    name: Linux Binary
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Setup Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: "3.11"
+
+      - name: Install dependencies
+        run: |
+          python -m pip install --upgrade pip
+          python -m pip install -e .
+          python -m pip install pyinstaller
+
+      - name: Capture package version
+        run: echo "AKOMA_VERSION=$(python setup.py --version)" >> $GITHUB_ENV
+
+      - name: Build binary
+        run: pyinstaller --onefile --name normattiva2md convert_akomantoso.py
+
+      - name: Copy XML fixture
+        run: cp test_data/20050516_005G0104_VIGENZA_20250130.xml .
+
+      - name: Run tests
+        run: make test
+
+      - name: Clean test outputs
+        run: rm -f test_output_*.md demo_output.md
+
+      - name: Package artifact
+        run: |
+          tar -C dist -czf normattiva2md-${AKOMA_VERSION}-linux-x86_64.tar.gz normattiva2md
+        env:
+          AKOMA_VERSION: ${{ env.AKOMA_VERSION }}
+
+      - name: Upload artifact
+        uses: actions/upload-artifact@v4
+        with:
+          name: normattiva2md-linux
+          path: normattiva2md-${{ env.AKOMA_VERSION }}-linux-x86_64.tar.gz
+
+  build-windows:
+    name: Windows Binary
+    runs-on: windows-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Setup Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: "3.11"
+
+      - name: Install dependencies
+        shell: pwsh
+        run: |
+          python -m pip install --upgrade pip
+          python -m pip install -e .
+          python -m pip install pyinstaller
+
+      - name: Capture package version
+        shell: pwsh
+        run: |
+          $version = python setup.py --version
+          echo "AKOMA_VERSION=$version" | Out-File -FilePath $env:GITHUB_ENV -Encoding utf8 -Append
+
+      - name: Build binary
+        shell: pwsh
+        run: pyinstaller --onefile --name normattiva2md convert_akomantoso.py
+
+      - name: Copy XML fixture
+        shell: pwsh
+        run: Copy-Item test_data/20050516_005G0104_VIGENZA_20250130.xml .
+
+      - name: Run unit tests
+        shell: pwsh
+        run: python -m unittest discover -s tests
+
+      - name: Exercise CLI scripts
+        shell: pwsh
+        run: |
+          python convert_akomantoso.py 20050516_005G0104_VIGENZA_20250130.xml test_output_python.md
+          ./dist/normattiva2md.exe 20050516_005G0104_VIGENZA_20250130.xml test_output_exe.md
+          normattiva2md 20050516_005G0104_VIGENZA_20250130.xml test_output_cmd.md
+
+      - name: Clean test outputs
+        shell: pwsh
+        run: Remove-Item test_output_*.md -ErrorAction SilentlyContinue
+
+      - name: Package artifact
+        shell: pwsh
+        env:
+          AKOMA_VERSION: ${{ env.AKOMA_VERSION }}
+        run: |
+          $artifactPath = Join-Path "dist" "normattiva2md-$env:AKOMA_VERSION-windows-x86_64.zip"
+          $binaryPath = Join-Path "dist" "normattiva2md.exe"
+          Compress-Archive -Path $binaryPath -DestinationPath $artifactPath -Force
+          Get-Item $artifactPath
+
+      - name: Upload artifact
+        uses: actions/upload-artifact@v4
+        with:
+          name: normattiva2md-windows
+          path: dist/normattiva2md-${{ env.AKOMA_VERSION }}-windows-x86_64.zip
+
+  release:
+    name: Publish Release
+    needs:
+      - build-linux
+      - build-windows
+    runs-on: ubuntu-latest
+    if: startsWith(github.ref, 'refs/tags/')
+    permissions:
+      contents: write
+    steps:
+      - name: Download artifacts
+        uses: actions/download-artifact@v4
+        with:
+          path: dist
+
+      - name: List download contents
+        run: ls -R dist
+
+      - name: Publish GitHub release
+        uses: softprops/action-gh-release@v1
+        with:
+          files: |
+            dist/normattiva2md-linux/*
+            dist/normattiva2md-windows/*
+          prerelease: ${{ contains(github.ref, '-rc') }}

normattiva2md-2.0.19/.gitignore

@@ -0,0 +1,68 @@
+# Ignora la directory di build di PyInstaller
+build/
+dist/
+
+# File Python compilati
+*.pyc
+__pycache__/
+
+# File temporanei e di sistema
+*~
+*.bak
+*.swp
+*.swo
+.DS_Store
+Thumbs.db
+
+# File di sistema specifici di Windows
+*.xml:Zone.Identifier
+
+# File di output generati
+output*.md
+test_output/
+test_*.md
+temp_*.xml
+*.debug.html
+
+# Conversioni di leggi specifiche (non committare output in root)
+anticorruzione.md
+codice_civile.md
+costituzione.md
+privacy.md
+codice_*.md
+legge_*.md
+
+# Build artifacts
+akoma2md.egg-info/
+build/
+dist/
+.env
+
+# Virtual environment
+venv/
+
+# pytest cache
+.pytest_cache/
+
+# ruff cache
+.ruff_cache/
+
+# Coverage reports
+.coverage
+htmlcov/
+
+# mypy cache
+.mypy_cache/
+
+# tox
+.tox/
+
+# Node modules (for .opencode)
+node_modules/
+
+# Virtual environments (already have venv/, but add .venv/)
+.venv/
+
+plans/
+tasks/todo.md
+tmp/

normattiva2md-2.0.19/.opencode/command/openspec-apply.md

@@ -0,0 +1,21 @@
+---
+agent: build
+description: Implement an approved OpenSpec change and keep tasks in sync.
+---
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+
+**Steps**
+Track these steps as TODOs and complete them one by one.
+1. Read `changes/<id>/proposal.md`, `design.md` (if present), and `tasks.md` to confirm scope and acceptance criteria.
+2. Work through tasks sequentially, keeping edits minimal and focused on the requested change.
+3. Confirm completion before updating statuses—make sure every item in `tasks.md` is finished.
+4. Update the checklist after all work is done so each task is marked `- [x]` and reflects reality.
+5. Reference `openspec list` or `openspec show <item>` when additional context is required.
+
+**Reference**
+- Use `openspec show <id> --json --deltas-only` if you need additional context from the proposal while implementing.
+<!-- OPENSPEC:END -->