v0.1.5: stop leaking "Plan is VALID" on syntax-only calls

.claude/skills/implement.md

@@ -1,22 +1,22 @@
 ---
 name: implement
-description: Implement a module or feature from the spec. Reads VALIDATOR_SPEC.md, checks existing code, writes implementation with tests.
+description: Implement a module or feature from the architecture reference. Reads CLAUDE.md and the existing pyval/ modules, then writes implementation with tests.
 ---
 
 ## Workflow
 
-1. **Read the spec** — `VALIDATOR_SPEC.md` is the source of truth. Find the section relevant to the module/feature.
+1. **Read the architecture reference** — `CLAUDE.md` (top-level) is the source of truth for pipeline phases, output modes, and conventions. Data-model shapes live in `pyval/models.py`; diagnostic templates live in `pyval/diagnostics.py` and `pyval/report_formatter.py`.
 2. **Check existing code** — Search `pyval/` for related implementations. Don't duplicate.
 3. **Check UPF API** — If the feature involves parsing, simulation, or state operations, verify the unified-planning API by reading its source or docs. Don't guess method signatures.
-4. **Implement** — Follow the module structure from the spec. Use the data models from `models.py`.
+4. **Implement** — Follow the module structure described in `CLAUDE.md`'s "Project Structure" section. Use the data models from `pyval/models.py`.
 5. **Write tests** — Every public function gets at least one classical and one numeric test case. Use inline PDDL strings, not fixture files.
 6. **Run tests** — `python3 -m pytest tests/ -v`
 
 ## Rules
 
-- The spec's data models (`ValidationResult`, `StepResult`, etc.) are the contract. Don't change their shape without updating the spec.
+- The data models in `pyval/models.py` (`ValidationResult`, `StepResult`, etc.) are the contract. Don't change their shape without updating every consumer and noting it in `CHANGELOG.md`.
 - All PDDL parsing goes through `unified-planning`'s `PDDLReader`. Do not write regex-based PDDL parsers.
-- Diagnostic messages must follow the templates in the spec's "Diagnostic Message Guidelines" section.
+- Diagnostic messages must follow the existing templates in `pyval/diagnostics.py` and `pyval/report_formatter.py` (precondition deficit reporting, repair-oriented messages, no leaking "Plan is VALID" when no plan was executed).
 - Handle both file paths and inline PDDL strings as input.
 - Numeric validation must track fluent values with float precision and report deficits.
 - Phase execution halts on first FATAL error — don't continue to Phase 3 if Phase 1 has FATAL errors.

.claude/skills/plan-review-simplify/SKILL.md

@@ -12,9 +12,10 @@ For the task described in $ARGUMENTS:
 ### Phase 1: Explore
 1. Read all relevant existing code using Grep and Glob
 2. Identify existing patterns that can be reused — especially:
-   - `pyval/models.py` for data model contracts
+   - `pyval/models.py` for data model contracts (and `to_json()` for the JSON output schema)
    - `pyval/validator.py` for pipeline orchestration patterns
-   - `VALIDATOR_SPEC.md` for output format and diagnostic templates
+   - `pyval/report_formatter.py` and `pyval/diagnostics.py` for output format and diagnostic templates
+   - `CLAUDE.md` for the architectural overview and conventions
 3. Check all modules under `pyval/` to understand cross-module impact
 4. Review `.claude/rules/` for validation semantics and UPF gotchas
 5. **Run `python3 -m pytest tests/ -v`** to verify baseline test state before planning changes
@@ -23,7 +24,7 @@ For the task described in $ARGUMENTS:
 Design the implementation approach covering:
 - **Objective**: One sentence describing the goal
 - **Analysis**: Current state, what needs to change, existing code to reuse
-- **Spec alignment**: Which sections of VALIDATOR_SPEC.md are affected?
+- **Reference alignment**: Which sections of `CLAUDE.md` (or which `pyval/` modules) are affected? Do output formats or diagnostic templates need updates in `report_formatter.py` / `diagnostics.py`?
 - **Pipeline phase**: Which phase does this change belong to? (Phase 1: syntax_checker, Phase 2: validator, Phase 3: plan_simulator, or cross-cutting: models/diagnostics/report_formatter)
 - **Models impact**: Does this change the models.py dataclass shapes? If so, which downstream modules break?
 - **Files to modify**: Table of file | action (create/modify/delete) | description
@@ -45,10 +46,10 @@ Before presenting the plan, review it for simplification and correctness:
 - Does `models.py` remain the single source of truth for data shapes?
 - Does the change avoid duplicating logic across pipeline phases?
 
-**Spec conformance:**
-- Do output formats match VALIDATOR_SPEC.md templates?
-- Do diagnostic messages follow the "Diagnostic Message Guidelines" section?
-- Do data models match the spec's dataclass definitions?
+**Reference conformance:**
+- Do output formats match the existing templates in `pyval/report_formatter.py`?
+- Do diagnostic messages follow the existing patterns in `pyval/diagnostics.py` (precondition deficits, repair advice, no leaking "Plan is VALID" when no plan was executed)?
+- Do data models match the dataclass definitions in `pyval/models.py`?
 - Does the CLI interface stay compatible with VAL's `Validate` command?
 
 **UPF correctness:**

.claude/skills/setup-project.md

@@ -15,7 +15,7 @@ description: Bootstrap the pyvalidator project structure. Creates pyproject.toml
    - Entry point: `[project.scripts] pyval = "pyval.cli:main"`
    - Include license, description, author metadata
 
-2. **Create `pyval/` package** (all modules from VALIDATOR_SPEC.md):
+2. **Create `pyval/` package** (modules per `CLAUDE.md`'s "Project Structure" section):
    ```
    pyval/__init__.py          # Public API: PDDLValidator, ValidationResult
    pyval/cli.py               # CLI entry point
@@ -55,7 +55,7 @@ description: Bootstrap the pyvalidator project structure. Creates pyproject.toml
 
 ## Rules
 
-- Follow VALIDATOR_SPEC.md for all module names and data model shapes
+- Follow `CLAUDE.md` for module names and the pipeline structure; data-model shapes come from `pyval/models.py`
 - Python >= 3.10 (for `match` statements and `X | Y` type union syntax)
 - `models.py` should be implemented first — other modules depend on its dataclasses
 - All `__init__.py` files should export public API names

.claude/skills/simplify/SKILL.md

@@ -13,7 +13,8 @@ $ARGUMENTS
 If no specific target is given, review the most recent changes (check git diff or the current plan).
 
 Key reference files for correctness and convention review:
-- VALIDATOR_SPEC.md — Authoritative spec for output formats, data models, and diagnostics
-- pyval/models.py — Data model contract (ValidationResult, StepResult, etc.)
+- CLAUDE.md — Authoritative architecture reference (pipeline phases, output modes, conventions)
+- pyval/models.py — Data model contract (ValidationResult, StepResult, etc.) and JSON schema via `to_json()`
+- pyval/diagnostics.py, pyval/report_formatter.py — Diagnostic message templates and output formats
 - .claude/rules/pddl-validation-semantics.md — Validation correctness rules
 - .claude/rules/upf-gotchas.md — UPF API pitfalls

CHANGELOG.md

@@ -6,6 +6,31 @@ Format: [Keep a Changelog](https://keepachangelog.com/en/1.1.0/). Versioning: [S
 
 ## [Unreleased]
 
+## [0.1.5] — 2026-05-19
+
+### Fixed
+- Plain-text report no longer claims `"All goals satisfied. Plan is VALID."`
+  on syntax-only calls (`validate_syntax(domain[, problem])`). The "Goal Check"
+  block in `pyval/report_formatter.py` ran unconditionally whenever
+  `is_valid=True`, even though no plan had been executed and no goal had been
+  checked. The block is now gated on `"execution" in result.phases`; the
+  syntax-only success path emits a single accurate line instead:
+  `"All syntax and consistency checks passed. No plan was executed."`.
+  Downstream consumers that previously string-stripped the leaked verdict
+  (pddl-copilot's `pddl-validator` plugin v2.2.0) can drop that workaround.
+
+### Added
+- `tests/test_report_formatter.py::test_plain_text_syntax_only_success_domain_and_problem`
+  and `::test_plain_text_syntax_only_success_domain_only` lock in the no-plan
+  semantics: no `"Plan is VALID/INVALID"`, no `"Goal Check"`, and the new
+  success line present.
+
+### Removed
+- `VALIDATOR_SPEC.md` — content was redundant with `CLAUDE.md` and the inline
+  module docs/diagnostic templates in `pyval/`. `CLAUDE.md` is now the single
+  authoritative architecture reference; data-model shapes are documented by
+  `pyval/models.py` and the JSON schema by `ValidationResult.to_json()`.
+
 ## [0.1.4] — 2026-04-20
 
 ### Fixed

CLAUDE.md

@@ -23,13 +23,13 @@ pyval/
 ├── report_formatter.py # Output formatting (plain text, JSON, trajectory table)
 └── models.py           # Dataclasses: ValidationResult, StepResult, etc.
 tests/
-├── domains/            # Test PDDL files (classical + numeric)
-└── ...
+├── conftest.py         # Shared PDDL fixtures (inline strings)
+└── test_*.py           # Module-level tests
 ```
 
 ## Specification
 
-`VALIDATOR_SPEC.md` is the authoritative reference. It defines the 3-phase pipeline, output formats, data models, and diagnostic templates. Read it before making design decisions.
+This file (`CLAUDE.md`) is the authoritative reference for architecture, pipeline phases, and conventions. Data-model shapes are defined in `pyval/models.py`; diagnostic templates live in `pyval/diagnostics.py` and `pyval/report_formatter.py`. JSON output schema is whatever `ValidationResult.to_json()` produces. Read these before making design decisions.
 
 ## Architecture
 
@@ -46,8 +46,8 @@ tests/
 
 ### Output Modes
 
-- **Plain text** (default) — VAL-like verbose output, optimized for LLM consumption.
-- **Structured JSON** — Machine-readable, see spec for schema.
+- **Plain text** (default) — VAL-like verbose output, optimized for LLM consumption. When no plan is provided (syntax-only validation), the report omits the `Plan is VALID/INVALID` verdict and the `Goal Check` block, and emits a single success line instead (since no plan was executed).
+- **Structured JSON** — Machine-readable; schema is whatever `ValidationResult.to_json()` (in `pyval/models.py`) emits.
 - **State trajectory** — Numeric fluent values at each plan step.
 
 ## Domain Knowledge for AI Agents
@@ -147,7 +147,7 @@ VAL is the C++ reference validator. PyVAL aims for output-format similarity (not
 - Pure Python, zero compiled dependencies. Must stay `pip install`-able.
 - Use `unified-planning` for all PDDL parsing and simulation — do not write custom parsers.
 - Test against both classical and numeric domains.
-- Diagnostic messages follow templates in `VALIDATOR_SPEC.md` section "Diagnostic Message Guidelines".
+- Diagnostic messages are generated in `pyval/diagnostics.py` and `pyval/report_formatter.py` — follow the existing templates there (precondition deficit reporting, repair-oriented messages, no leaking "Plan is VALID" when no plan was executed).
 - CLI interface mirrors VAL's `Validate` command for familiarity.
 - **Update `CHANGELOG.md`** after every implementation milestone (new module, feature, or fix). Keep entries under `[Unreleased]` until a version is tagged.
 

README.md

@@ -76,7 +76,7 @@ pip install -e ".[dev]"
 pytest
 ```
 
-See `VALIDATOR_SPEC.md` for the full specification and `CLAUDE.md` for architecture notes.
+See `CLAUDE.md` for architecture notes and the validation pipeline overview.
 
 ## License