Repository navigation
Releases: pathmodeio/validate-intentspec-action
Release list
v1.2.5: reads the SPEC.md section 2 heading aliases
The action now reads the heading aliases in IntentSpec SPEC.md section 2. When ## Objective is absent, ## Problem and then ## Why carry the objective, and ## Proposed outcome stands in for an absent ## Outcomes. The first heading present is the section, even when it is empty, and aliases never merge. ## What is not an alias: it usually states the solution, and an outcome is the observable result.
What changes for you: a sectioned intent.md that wrote its objective only under ## Problem or ## Why used to fail with "required property 'objective'" for a field it visibly had. It now validates. A document using the canonical headings validates exactly as under v1.2.4.
It also keeps this action in step with the normalization corpus published at intentspec.org, which gains four cases for these aliases. v1.2.4 fails three of them.
@v1 now points at this release. Nothing to change if you use @v1; bump to @v1.2.5 if you pin exact versions.
Initial Release
v1.2.4: runs on Node 24
The action now declares node24. GitHub has deprecated Node 20 for actions and was already running this one on Node 24, with a deprecation warning in every workflow that used it. That warning is gone.
Validation is unchanged: dist/ rebuilds byte-identical to v1.2.3, and it still checks IntentSpec v1.2 with the same schema and anchor rules.
@v1 now points at this release. Nothing to change if you use @v1; bump to @v1.2.4 if you pin exact versions.
v1.2.3 — the normalization corpus is fetched, not vendored
v1.2.2 added the normalization corpus but shipped a copy of it. A copy passes forever against whatever it was copied at, which is precisely the staleness the corpus exists to prevent: it is the artifact holding four independent implementations of SPEC.md section 2 to one reading of a document, so a stale copy is worse than no copy at all.
The corpus is now fetched from intentspec.org/normalization-corpus.json at test time, alongside the existing schema and anchors drift checks.
The split that matters
Data is fetched. Code stays vendored. corpus-compare.mjs is copied and reviewed rather than fetched, because pulling executable code into a test at runtime is a supply-chain hole, not a freshness fix.
A fetch failure fails loudly and is skipped only under SKIP_DRIFT=1, so a site outage never reads as conformance.
Usage is unchanged: uses: pathmodeio/validate-intentspec-action@v1
v1.2.2 — enforceable parity via the published normalization corpus
Vendoring kept this Action's normalizer aligned with the IntentSpec reference by convention. Now it is enforceable.
test/normalization-corpus.json is the same file run by pathmodeio/intentspec and by Pathmode's browser and MCP parsers: markdown in, exact normalized object out. Accept/reject fixtures cannot catch two implementations agreeing that a document is valid while disagreeing about what it says, which is the whole promise of one format.
On its first run it caught exactly that. The reference accepted ASCII -> for edge cases while the shipped Pathmode parsers accepted → and :, so the same document produced different edge cases depending on which tool read it. All implementations now accept all four documented forms:
- **scenario**: expected behavior
- scenario: expected behavior
- scenario -> expected behavior
- scenario → expected behavior
Also fixes package metadata: the package name was cli, the license field said ISC while LICENSE is MIT, and the author was blank.
Usage is unchanged: uses: pathmodeio/validate-intentspec-action@v1
v1.2.1 — validate the normalized document, not just the frontmatter
IntentSpec defines two markdown serializations, and this Action only read one of them.
A conforming sectioned intent.md, the shape real authoring templates produce, was rejected for missing fields it visibly contained: the validator read YAML frontmatter and validated that object, so lists living under ## headings were invisible to it. SPEC.md section 1 is explicit that a validator reading only frontmatter is the defective party, and this was that validator.
What changed
src/normalize.ts implements SPEC.md section 2, vendored from the reference implementation in pathmodeio/intentspec:
- frontmatter wins for scalars, a non-empty section wins for lists
- fenced code blocks and HTML comments are stripped before structure is read, so template guidance never becomes content
## Verificationflattens to an array of strings, because the schema defines no object form- malformed frontmatter fails the whole document rather than silently falling back to the body
Behavioral parity is held by running the standards repo's conformance fixtures here, including one built from the real pathmode-intent OpenSpec template.
Compatibility
Frontmatter-only documents validate exactly as before; the v1.0 and v1.2 fixtures still pass unchanged. This release only adds the documents that should always have been accepted.
Also removes a debug log that printed the environment on every run.
Usage is unchanged: uses: pathmodeio/validate-intentspec-action@v1
v1.0.8 - Schema cleanup
Full Changelog: v1.0.7...v1.0.8
v1.0.7 - Bugs smashed
v1.0.6 - debugging more
Full Changelog: v1.0.5...v1.0.6
v1.0.5 - fix after fix
Full Changelog: v1.0.4...v1.0.5