Repository navigation
Conversation
NejcS
changed the title
A functionality is a `# <func-id>` heading followed by its body: a prose statement line and the `- ` bullets indented under it. The parse result entry carries the id, the body markdown, its linked resources and empty conformance and acceptance test lists. A flush-left `- ` list in functional specs, and an acceptance tests or conformance tests section in a core spec, are the old syntax; the error names the migrate-plain-syntax skill. The nested acceptance test code is removed and every fixture is converted.
A func-id has only lowercase letters, digits and hyphens and is unique in its module. The errors name the line, the module and, for a duplicate, the line of the first use.
get_frids yields the func-ids in file order, and the helpers that take a frid take a func-id. get_specifications_for_frid returns the conformance and acceptance scenarios of the functionality, and collect_linked_resources covers the links in them. The legacy tree walk over sections, ID and Heading is removed.
A test plain file binds to one functionality with the frontmatter keys module and func_id and holds a conformance tests section followed by an acceptance tests section. A scenario is a `# <scenario-id>` heading and its text, kept verbatim. Liquid and linked resources work as in a core spec; the concepts of the scenarios are checked once the bound module is known.
Every .plain file under the test folders is read as a test plain file, bound to a module of the chain and one of its func-ids, checked against the concepts of that module, and merged into the functionality in discovery order. With conformance-tests-script in the config, every functionality needs a conformance scenario; the error names it as <module>:<func-id> and the add-test-scenarios skill. The config keys test-dir and conformance-tests-script are read like template-dir.
check and parse take --test-dir, repeatable, which overrides the test-dir config key and the default tests folder. The parse output is format version 2: the functionality trees carry the merged scenarios, resources covers the links in them, and test_plain_files maps each file to the functionality it binds to. The README describes the new syntax.
NejcS
force-pushed
the
feat/explicit-test-scenarios
branch
from
October 19, 2026 12:35
ffc460d to
9d2c4b1
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
plain-parser reads the current ***plain syntax:
# func-idheadings in functional specs and test plain files with explicit test scenarios.Functional specs
A functionality starts with a
# <func-id>heading. Its body is one statement line and the bullets indented under it. A func-id has only lowercase letters, digits and hyphens, and is unique in its module.Test plain files
A test plain file binds to one functionality with
module:andfunc_id:in its frontmatter. It has a conformance tests section and an acceptance tests section. Each scenario is a# <scenario-id>heading followed by free text, which the parser keeps as written. The parser reads every.plainfile undertestsnext to the module, or under the folders given with--test-diror the config keytest-dir. It checks that each file binds to an existing functionality, that the concepts in the scenarios are defined, that linked files exist, and that scenario-ids are unique per functionality.Completeness
When the config names a
conformance-tests-script, every functionality of every module in the chain needs at least one conformance scenario. The error names the functionality as<module>:<func-id>and theadd-test-scenariosskill.Old syntax
A flush-left
-list in functional specs and an acceptance tests section in a core spec are errors. The message gives the file, the line and themigrate-plain-syntaxskill.Parse output
plain-parser parseprints format version 2. Each functionality carries its id, its text and its scenarios, and a newtest_plain_filesmap lists every test plain file with the functionality it binds to. A reader of format version 1 must be updated. Today only plain-forge reads the output, and it reads only the exit code.Before it works for users
A release with a
vX.Y.Ztag publishes the package to PyPI. After that, plain-healthcheck in plain-forge can run its parser step again. The codeplain client and backend keep their own parser copies until phase 3.