Completeness Checklist

The chant dev check-lexicon command evaluates a lexicon directory against three tiers of completeness. Run it from anywhere:

chant dev check-lexicon lexicons/my-lexicon

Pass --format json for machine-readable output.

Tier 1 — Required

These must all pass for the command to exit 0. CI should gate on this.

Check	What it verifies
src/plugin.ts exists	Plugin entry point
src/serializer.ts exists	Build output serializer
At least 1 lint rule	src/lint/rules/*.ts (not index.ts)
At least 1 post-synth check	src/lint/post-synth/*.ts (not index.ts/helpers.ts)
src/lsp/completions.ts exists	LSP completion provider
src/lsp/hover.ts exists	LSP hover provider
dist/manifest.json exists	Lexicon bundle was built
At least 1 example	Non-empty subdirectory in examples/
plugin.test.ts exists	Plugin unit test
serializer.test.ts exists	Serializer unit test
At least 1 .mdx doc page	Documentation exists

Tier 2 — Recommended

Warnings — these make the lexicon useful in practice.

Check	What it verifies
Uncommented mcpTools	MCP tool contributions active
Uncommented mcpResources	MCP resource contributions active
Uncommented skills	AI skills active
Uncommented detectTemplate	Template detection active
Uncommented initTemplates	Init templates active
At least 1 composite	src/composites/*.ts (not index.ts)
At least 3 examples	Broader usage coverage
completions.test.ts exists	LSP completions tested
hover.test.ts exists	LSP hover tested
default-labels.test.ts exists	Default labels/annotations tested
coverage.test.ts exists	Coverage analysis tested
coverage.ts implemented	No “not yet implemented” placeholder
At least 8 doc pages	Comprehensive documentation — recommended topics: overview, getting-started, resources, intrinsics, pseudo-parameters, composites, lint-rules, importing
At least 15 post-synth checks	Covering security, correctness, and best practices (see Post-Synth Check Guide)
At least 3 skills	Core patterns, cloud/platform-specific, advanced patterns (see Skills Authoring Guide)
At least 3 initTemplates	Default, domain-specific variant 1, domain-specific variant 2

Tier 3 — Thoroughness

Informational — tracks depth of testing and feature coverage.

Check	What it verifies
Each lint rule has a .test.ts	Per-rule or consolidated test coverage (e.g. rules.test.ts)
Each post-synth has a .test.ts	Per-check or consolidated test coverage (e.g. post-synth.test.ts)
import/parser.test.ts exists	Import parser tested
import/generator.test.ts exists	Import generator tested
import/roundtrip.test.ts exists	Import round-trip tested
typecheck.test.ts exists	Type-level verification
roundtrip.test.ts exists	Serialize/deserialize round-trip
At least 5 composites	Rich composition library
src/actions/ with actions	Automation actions
At least 5 examples with tests	Tested usage patterns (per-example or consolidated root test)
validate.ts checks at least 30 required names	Deep artifact validation covering resources, property types, and bundle files
Composite tests exist	composites.test.ts covering all composites (props, types, defaults, dependencies)

Recommended Post-Synth Check Categories

When designing post-synth checks, aim for coverage across these categories:

Category	Examples
Security	Encryption enabled, TLS version, HTTPS-only, access control, identity configuration
Correctness	Required fields present, valid values, correct dependencies
Best Practices	Naming conventions, tagging/labeling, resource configuration defaults
Deprecation	Outdated API versions, legacy features, deprecated properties

See Testing Your Lexicon for patterns, mock helpers, and checklists for each test file.

Complete lexicon file tree

Use the AWS lexicon as reference for full coverage:

lexicons/my-lexicon/
├── src/
│   ├── plugin.ts              # LexiconPlugin entry point
│   ├── plugin.test.ts
│   ├── serializer.ts          # Build output serializer
│   ├── serializer.test.ts
│   ├── index.ts               # Re-exports
│   ├── coverage.ts            # Coverage analysis
│   ├── validate.ts            # Artifact validation
│   ├── validate-cli.ts
│   ├── codegen/
│   │   ├── generate.ts        # Code generation pipeline
│   │   ├── generate-cli.ts
│   │   ├── naming.ts          # Naming strategy
│   │   ├── package.ts         # Bundle packaging
│   │   └── docs.ts            # Docs generation
│   ├── spec/
│   │   ├── fetch.ts           # Upstream schema fetching
│   │   └── parse.ts           # Schema parsing
│   ├── lint/
│   │   ├── rules/             # Lint rules + tests
│   │   └── post-synth/        # Post-synthesis checks + tests
│   ├── lsp/
│   │   ├── completions.ts     # LSP completions
│   │   ├── completions.test.ts
│   │   ├── hover.ts           # LSP hover
│   │   └── hover.test.ts
│   ├── composites/            # Composite resources
│   ├── actions/               # Automation actions
│   ├── import/                # Template parser + generator
│   └── generated/             # Generated artifacts (do not edit)
├── dist/                      # Built bundle
├── examples/                  # Usage examples with tests
├── docs/                      # Starlight docs site
├── package.json
├── tsconfig.json
└── justfile

Suggested implementation order

After scaffolding with chant init lexicon:

1. Implement src/spec/fetch.ts and src/spec/parse.ts
2. Implement src/codegen/generate.ts and src/codegen/naming.ts
3. Run just generate to produce types
4. Implement src/serializer.ts
5. Write lint rules in src/lint/rules/
6. Add post-synth checks in src/lint/post-synth/
7. Implement LSP completions and hover
8. Build examples
9. Generate docs

Reference implementations

• K8s — the most mature lexicon: 20 post-synth checks, 3 skills, 3 initTemplates, 33 required names, full docs site
• Azure — comprehensive ARM template lexicon with 20 post-synth checks, 3 skills, and 11 doc pages
• AWS — full coverage across all tiers, including per-rule tests and composites
• Flyway — good example of per-rule testing patterns with test helpers