Indexion Sdd

# indexion SDD (Spec-Driven Development)

Bridge indexion's quantitative spec alignment tools with SDD agent workflows (cc-sdd, codex, etc.).

Provides: RFC/document → SDD draft, spec↔impl drift detection, and a validation loop
that feeds indexion's quantitative results into agent-driven qualitative review.

## When to Use

- User wants to implement an RFC or specification as a library/package
- User asks to verify spec-to-implementation conformance
- User wants to set up a SDD project with cc-sdd + codex + indexion
- User says "run the SDD loop" or "validate against the spec"
- After `codex spec-impl` completes, to check for drift before merging

## Important

- **Set cc-sdd `--lang` to match the implementation language, not the
  spec language.** If code is in English, use `--lang en`. Mismatched
  languages break `spec align diff` vocabulary matching.

## Process: RFC → Implementation → Validation

### Step 0: Project Setup

```bash
# Create project directory
mkdir my-rfc-impl && cd my-rfc-impl

# Install cc-sdd for your agent — set lang to match the code language
npx cc-sdd@latest --codex-skills --lang en --yes   # codex (skills mode)
npx cc-sdd@latest --claude-skills --lang en --yes   # claude (skills mode)

# Initialize project (language-specific)
# e.g., cargo init, npm init, moon new, etc.

# Initialize git
git init && git add -A && git commit -m "init"
```

**Verify indexion is available** before proceeding. The drift gate
(Step 2.5) and validation loop (Step 3) depend on it:

```bash
indexion --version                       # must be installed
indexion kgf edges <any-source-file>     # must detect language and show edges
```

If `indexion` is not installed, install it first. If the KGF for your
spec format is not recognized, update `indexion` to a version that
includes it. See Step 2.7 for the fallback when this cannot be resolved.

### Step 1: Specification → SDD Draft (indexion)

Fetch the specification document (RFC, ISO standard, etc.) and prepare it:

```bash
# For RFC: save as markdown or .rfc.txt
indexion spec draft --output .kiro/specs/<feature>/requirements.md rfc_document.md

# For ISO/IEC standards: extract text from PDF with cleanup, then draft
python3 scripts/extract_iso_text.py spec.pdf <start_page> <end_page> spec.spec.txt
indexion spec draft --output .kiro/specs/<feature>/requirements.md spec.spec.txt

# Create spec.json (set requirements.generated=true, approved=true)
```

The output uses `### Requirement N:` and `#### N.M:` hierarchy matching
cc-sdd's expected ID format. The agent's `$kiro-spec-requirements` phase will
further refine into EARS format with acceptance criteria.

**Supported specification formats:**
| Format | Extension | KGF spec |
|--------|-----------|----------|
| RFC plaintext | `.rfc.txt` | `rfc-plaintext` |
| ISO/IEC technical document | `.spec.txt` | `technical-document` |
| Markdown (README, etc.) | `.md` | `markdown` |

### Step 1.5: Specification Fidelity Check (indexion)

After writing requirements, verify they cover the source specification:

```bash
# Check requirements ↔ original spec alignment
# (spec align now accepts document files as impl when no code files are found)
indexion spec align diff .kiro/specs/<feature>/requirements.md spec.spec.txt \
  --format markdown --threshold 0.3

# SPEC_ONLY items = requirements not covered by original spec
# DRIFTED items = requirements using different vocabulary from original spec
```

**Traceability chain:** `spec align` works between documents at the
same abstraction level. For full traceability, check each adjacent pair:

```bash
# 1. Source spec ↔ requirements (fidelity)
indexion spec align diff requirements.md source-spec.spec.txt --threshold 0.3
# 2. Requireme