What is missing
architecture/specs/PDSL.md states a normative ordering rule for the deferred-continue
idiom: CONTINUE <unit-or-phase> after user.reply must be written before the WAIT
it defers past, because WAIT + STOP_TURN is a hard turn boundary and anything after it
in the same DO block is unreachable.
Nothing enforces it. No validator rule covers the ordering, and no test in
tests/test_pdsl_keywords.py or tests/test_pdsl_validate_cli.py asserts it. The rule
exists only as prose, so an author can violate it and CI stays green.
Why it matters
An unreachable CONTINUE is the exact defect the rule was written to prevent: the resume
target looks declared, the workflow reads as if it continues, and at runtime the turn
simply ends. It fails silently and it looks correct in review.
Existing guards are adjacent but do not cover this: the dangling-continuation-target check
asserts that each entry into a gate sets its return unit, not where the CONTINUE sits
relative to its WAIT.
What enforcement has to handle
- Intra-line ordering, not just line ordering. In the shipped corpus the
CONTINUE and
the WAIT usually share one line, e.g.
EMIT "..."; CONTINUE PlanPhase2Decompose after user.reply; WAIT user.reply; STOP_TURN.
A check that compares line numbers alone will pass every real violation it is meant to
catch, so it has to compare positions within a line.
- A new rule id. Whether any existing
PDSL7xx code can carry this needs deciding
before one is added.
- A baseline decision. A new rule has to be run against the whole corpus first: if
there are pre-existing violations it lands as a warning with a recorded baseline rather
than as an error.
Acceptance
- A validator rule flags a
CONTINUE ... after user.reply that follows its WAIT/STOP_TURN
within one DO block, and accepts the corpus's existing before-the-WAIT form.
- At least one test drives the rule through the CLI entry point, not only the in-process
validator, so exit-code mapping and output rendering are covered.
- The shipped corpus validates clean, or its known violations are recorded in a baseline.
Raised in review of #167, which documents the rule but is docs-only and adds no validator
change, and restated there after merge.
What is missing
architecture/specs/PDSL.mdstates a normative ordering rule for the deferred-continueidiom:
CONTINUE <unit-or-phase> after user.replymust be written before theWAITit defers past, because
WAIT+STOP_TURNis a hard turn boundary and anything after itin the same
DOblock is unreachable.Nothing enforces it. No validator rule covers the ordering, and no test in
tests/test_pdsl_keywords.pyortests/test_pdsl_validate_cli.pyasserts it. The ruleexists only as prose, so an author can violate it and CI stays green.
Why it matters
An unreachable
CONTINUEis the exact defect the rule was written to prevent: the resumetarget looks declared, the workflow reads as if it continues, and at runtime the turn
simply ends. It fails silently and it looks correct in review.
Existing guards are adjacent but do not cover this: the dangling-continuation-target check
asserts that each entry into a gate sets its return unit, not where the
CONTINUEsitsrelative to its
WAIT.What enforcement has to handle
CONTINUEandthe
WAITusually share one line, e.g.EMIT "..."; CONTINUE PlanPhase2Decompose after user.reply; WAIT user.reply; STOP_TURN.A check that compares line numbers alone will pass every real violation it is meant to
catch, so it has to compare positions within a line.
PDSL7xxcode can carry this needs decidingbefore one is added.
there are pre-existing violations it lands as a warning with a recorded baseline rather
than as an error.
Acceptance
CONTINUE ... after user.replythat follows itsWAIT/STOP_TURNwithin one
DOblock, and accepts the corpus's existing before-the-WAITform.validator, so exit-code mapping and output rendering are covered.
Raised in review of #167, which documents the rule but is docs-only and adds no validator
change, and restated there after merge.