[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-78862":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":14,"subscribersCount":14,"size":14,"stars1d":15,"stars7d":16,"stars30d":17,"stars90d":14,"forks30d":14,"starsTrendScore":18,"compositeScore":19,"rankGlobal":9,"rankLanguage":9,"license":9,"archived":20,"fork":20,"defaultBranch":21,"hasWiki":22,"hasPages":20,"topics":23,"createdAt":9,"pushedAt":9,"updatedAt":24,"readmeContent":25,"aiSummary":26,"trendingCount":14,"starSnapshotCount":14,"syncStatus":27,"lastSyncTime":28,"discoverSource":29},78862,"Acceptance-Pipeline-Specification","unclebob\u002FAcceptance-Pipeline-Specification","unclebob","Portable acceptance pipeline specification",null,"Go",148,7,3,0,1,4,24,5,46.11,false,"main",true,[],"2026-06-12 04:01:24","# Acceptance Pipeline Specification\n\n## Purpose\n\nThis document defines a portable acceptance-test pipeline that agents can install in a new project. The pipeline turns a small Gherkin feature file into a JSON intermediate representation, generates executable acceptance tests from that IR, runs those tests, and runs acceptance mutation against the Gherkin examples to measure whether those tests are fully connected to the application they test.\n\nIn this specification, acceptance mutation means mutating Gherkin example values in the specification-derived JSON IR. It does not mean conventional mutation testing of application source code.\n\nThis specification is intentionally implementation-language and project neutral. The strategy it implements should work for any language and any project.\n\n## Pipeline Overview\n\nThe pipeline has two operating modes.\n\nNormal acceptance run:\n\n```text\nfeature file\n  -> gherkin parser\n  -> JSON IR\n  -> acceptance generator\n  -> generated acceptance tests\n  -> project test runner\n```\n\nAcceptance mutation run:\n\n```text\nfeature file\n  -> gherkin parser\n  -> base JSON IR\n  -> mutator builds one changed IR per mutation\n  -> acceptance generator creates tests for each changed IR\n  -> project test runner evaluates each mutation\n  -> mutation report\n```\n\nThe normal run proves that the project satisfies the feature file. The acceptance mutation run probes whether the generated acceptance tests are strong enough to fail when example data is changed.\n\n## Required Project Layout\n\nA conforming setup should create these paths or their project-specific equivalents:\n\n```text\nfeatures\u002Fa-feature.feature\nbuild\u002Facceptance\u002Fa-feature.json\nbuild\u002Facceptance-mutation\u002F\nacceptance\u002Fgenerated\u002F\n```\n\nRecommended command entry points:\n\n```text\ngherkin-parser \u003Cfeature-file> \u003Cjson-output>\nacceptance-generator \u003Cjson-ir> \u003Cgenerated-test-output>\ngherkin-mutator [options]\n```\n\n### Generated Tests\n\nThe exact executable format of the generated tests is project-specific. Generated tests typically run in the same environment as the project's unit tests, but they should be kept in a separate generated-test location.\n\n## Required Components\n\nAn implementation must provide:\n\n1. Gherkin parser: Reads the supported Gherkin subset and writes the JSON IR.\n2. JSON IR reader\u002Fwriter: Loads and stores the canonical feature representation.\n3. Acceptance generator: Converts JSON IR into executable acceptance tests for the project.\n4. Acceptance runtime: Expands the IR into scenario executions and dispatches steps to project handlers.\n5. Project step handlers: Bind exact step text to project behavior and assertions.\n6. Test runner adapter: Runs generated tests and captures status, output, and error text.\n7. Mutator: Builds and applies deterministic example-value mutations.\n8. Acceptance mutation reporter: Emits text or JSON reports and returns the correct exit code.\n9. Convenience scripts: Provide a stable one-command normal run and acceptance mutation run.\n\n## Normal Acceptance Script\n\nAgents should install a script equivalent to this POSIX shell example:\n\n```sh\n#!\u002Fbin\u002Fsh\nset -eu\n\nmkdir -p build\u002Facceptance acceptance\u002Fgenerated\n\ngherkin-parser \\\n  features\u002Fa-feature.feature \\\n  build\u002Facceptance\u002Fa-feature.json\n\nacceptance-generator \\\n  build\u002Facceptance\u002Fa-feature.json \\\n  acceptance\u002Fgenerated\u002Fa-feature_acceptance_test.\u003Ctest-extension>\n\n\u003Cproject-test-command> acceptance\u002Fgenerated\n```\n\nScript requirements:\n\n1. Stop on the first failed command.\n2. Create required output directories before writing files.\n3. Treat parser, generator, and test failures as script failures.\n4. Never run generated tests against the source feature file directly; generated tests must be created from the JSON IR every time.\n\n## Acceptance Mutation Script\n\nAgents should install a script equivalent to this POSIX shell example:\n\n```sh\n#!\u002Fbin\u002Fsh\nset -eu\n\ngherkin-mutator --feature features\u002Fa-feature.feature \"$@\"\n```\n\nThe mutator command owns parsing, Gherkin example mutation, generation, test execution, and reporting.\n\n## Gherkin Parser Command\n\nThe parser command accepts exactly two positional arguments:\n\n```text\ngherkin-parser \u003Cfeature-file> \u003Cjson-output>\n```\n\nExit codes:\n\n```text\n0  parse succeeded and JSON IR was written\n1  input\u002Foutput\u002Fparsing error\n2  wrong command usage\n```\n\nThe parser reads the feature file, parses the supported Gherkin subset, and writes pretty-printed JSON IR.\n\n## Supported Gherkin Syntax\n\nThe parser accepts a small, deterministic subset of Gherkin.\n\n### General Rules\n\nBlank lines are ignored.\n\nLines whose first non-whitespace character is `#` are ignored.\n\nLeading and trailing whitespace are ignored before parsing each line.\n\nFree-form lines that do not match supported syntax are ignored. This allows brief feature descriptions, but they are not preserved in the IR.\n\nThe parser must preserve the order of background steps, scenarios, scenario steps, and example rows. Example columns become object keys in the JSON IR; consumers that need deterministic key traversal must sort keys explicitly.\n\n### Feature\n\nA feature file must contain a feature declaration:\n\n```gherkin\nFeature: \u003Cfeature name>\n```\n\nThe feature name is the trimmed text after `Feature:`.\n\nA missing feature declaration is an error.\n\nIf multiple feature declarations appear, a conforming feature should treat that as invalid or use the last declaration consistently. New projects should use exactly one.\n\n### Background\n\nA feature may contain one background:\n\n```gherkin\nBackground:\n  Given \u003Cstep text>\n  And \u003Cstep text>\n```\n\nBackground steps are prepended to every scenario execution by the acceptance runtime.\n\nIf multiple background sections are present, portable behavior is undefined. New projects should use at most one.\n\n### Scenarios\n\nThe parser accepts both `Scenario:` and `Scenario Outline:`:\n\n```gherkin\nScenario: \u003Cscenario name>\n  Given \u003Cstep text>\n  When \u003Cstep text>\n  Then \u003Cstep text>\n\nScenario Outline: \u003Cscenario name>\n  Given \u003Cstep text containing \u003Cparameter_name>>\n\n  Examples:\n    | parameter_name |\n    | value          |\n```\n\nBoth forms produce the same JSON IR shape. Scenarios with examples can be mutated.\n\nA scenario without examples is valid and executes once with an empty example object. Such scenarios cannot be mutated.\n\n### Steps\n\nSupported step keywords:\n\n```text\nGiven\nWhen\nThen\nAnd\n```\n\nA step line must be one of:\n\n```gherkin\nGiven \u003Cstep text>\nWhen \u003Cstep text>\nThen \u003Cstep text>\nAnd \u003Cstep text>\n```\n\nThe keyword is stored separately from the step text. The step text is the trimmed text after the keyword.\n\nA step outside a background or scenario is an error.\n\n### Parameters\n\nParameters are placeholders inside step text:\n\n```text\n\u003Cparameter_name>\n```\n\nParameter names must match:\n\n```text\n[A-Za-z0-9_]+\n```\n\nThe parser records parameter names in the order they appear in each step's text. Repeated parameter names should be preserved as repeated entries.\n\nParameters are not expanded by the parser. They remain in the step text and are resolved by the acceptance runtime using the current example object.\n\n### Examples Tables\n\nAn examples section starts with:\n\n```gherkin\nExamples:\n```\n\nIt must appear inside a scenario.\n\nRows are pipe-delimited:\n\n```gherkin\n| name | count |\n| one  | 1     |\n| two  | 2     |\n```\n\nParsing rules:\n\n1. A row is recognized only when the trimmed line starts with `|`.\n2. Leading and trailing `|` characters are removed.\n3. The remaining text is split on `|`.\n4. Each cell is trimmed.\n5. The first row after `Examples:` is the header row.\n6. Every data row must have the same number of cells as the header row.\n7. Header names become JSON object keys.\n8. Cell values are stored as strings.\n\nUnsupported syntax:\n\n```text\ntags\nrules\nlocalized keywords\nescaped pipes\nquoted table cells\nmultiline cells\ndoc strings\ndata tables attached to steps\nstep-level comments with semantic meaning\n```\n\n## JSON Intermediate Representation\n\nThe JSON IR is the canonical data structure consumed by the generator, runtime, and mutator.\n\n### Feature Object\n\n```json\n{\n  \"name\": \"Feature name\",\n  \"background\": [\n    {\n      \"keyword\": \"Given\",\n      \"text\": \"a configured project state\",\n      \"parameters\": []\n    }\n  ],\n  \"scenarios\": [\n    {\n      \"name\": \"Scenario name\",\n      \"steps\": [\n        {\n          \"keyword\": \"Then\",\n          \"text\": \"the result is \u003Cresult>\",\n          \"parameters\": [\"result\"]\n        }\n      ],\n      \"examples\": [\n        {\n          \"result\": \"accepted\"\n        }\n      ]\n    }\n  ]\n}\n```\n\nRequired fields:\n\n```text\nname       string\nscenarios  array of scenario objects\n```\n\nOptional fields:\n\n```text\nbackground  array of step objects; omit or use [] when absent\n```\n\n### Scenario Object\n\n```json\n{\n  \"name\": \"Scenario name\",\n  \"steps\": [],\n  \"examples\": []\n}\n```\n\nRequired fields:\n\n```text\nname      string\nsteps     array of step objects\nexamples  array of objects whose keys and values are strings\n```\n\nIf `examples` is empty, the runtime must execute the scenario once with an empty example object.\n\n### Step Object\n\n```json\n{\n  \"keyword\": \"Given\",\n  \"text\": \"the input is \u003Cinput>\",\n  \"parameters\": [\"input\"]\n}\n```\n\nRequired fields:\n\n```text\nkeyword  one of \"Given\", \"When\", \"Then\", \"And\"\ntext     string\n```\n\nOptional fields:\n\n```text\nparameters  array of strings; omit or use [] when no placeholders are present\n```\n\nThe `parameters` field is derived from `text`. Generators and runtimes should treat `text` as authoritative and may validate that `parameters` agrees with the placeholders found in `text`.\n\n### Example Object\n\nAn example object maps parameter or column names to string values:\n\n```json\n{\n  \"input\": \"42\",\n  \"command\": \"calculate total\",\n  \"expected_status\": \"accepted\"\n}\n```\n\nAll values must be strings, even when they represent numbers, lists, commands, booleans, messages, or enums.\n\n## Acceptance Generator Command\n\nThe generator command accepts exactly two positional arguments:\n\n```text\nacceptance-generator \u003Cjson-ir> \u003Cgenerated-test-output>\n```\n\nExit codes:\n\n```text\n0  generation succeeded\n1  input\u002Foutput\u002Fgeneration error\n2  wrong command usage\n```\n\nThe generator reads JSON IR and writes executable tests that execute the scenarios and examples represented by that IR.\n\nGenerator requirements:\n\n1. Generated tests must embed or load the JSON IR supplied to the generator.\n2. Generated tests must not parse the source Gherkin file.\n3. Generated tests must run every scenario execution represented by the IR.\n4. Generated tests must fail when the runtime reports an unsupported step, invalid example value, or failed assertion.\n5. The generated output must be deterministic for a fixed IR.\n\nThe generated test format is implementation-specific.\n\n## Acceptance Runtime\n\nThe runtime is the shared execution engine used by generated tests.\n\nRuntime responsibilities:\n\n1. Load or receive the JSON IR.\n2. Expand each scenario into scenario executions.\n3. For scenarios with examples, create one execution per example row.\n4. For scenarios without examples, create one execution with an empty example object.\n5. Prepend background steps to each execution.\n6. Execute steps in order.\n7. Resolve placeholder values from the current example object.\n8. Route each step to a project step handler.\n9. Report any unsupported step, missing value, invalid conversion, or failed assertion as a test failure.\n\nSuggested execution naming:\n\n```text\n\u003Cscenario name>\u002Fexample_\u003Cone-based-index>\n```\n\nFor scenarios without examples, use `example_1` or another stable name.\n\n## Step Handler Contract\n\nStep handlers are the project-specific adapter layer. They connect exact Gherkin step text to project behavior.\n\nThe portable baseline matches handlers by exact `text` value, not by keyword:\n\n```text\n\"the result is \u003Cresult>\"\n```\n\nHandler inputs:\n\n```text\nworld\u002Fstate object for the current scenario execution\nexample values for the current scenario execution\n```\n\nHandler outputs:\n\n```text\nsuccess\nfailure with diagnostic text\n```\n\nHandler requirements:\n\n1. A scenario execution must get a fresh world\u002Fstate object.\n2. Background and scenario steps within the same execution share the same world\u002Fstate object.\n3. Handlers must fetch placeholder values by name from the current example object.\n4. Handlers must parse string values into project types as needed.\n5. Missing, malformed, or semantically invalid values must fail the current test.\n6. Unsupported step text must fail the current test.\n\nA project may add regex or expression matching, but exact text matching is the portable baseline.\n\n## Test Runner Adapter\n\nThe test runner adapter runs generated acceptance tests.\n\nInputs:\n\n```text\ngenerated test path or directory\ntimeout or cancellation signal\n```\n\nOutputs:\n\n```text\npassed?       boolean\noutput        combined standard output\u002Ferror or equivalent diagnostic text\nerror text    infrastructure error, command failure text, or empty string\nduration      elapsed time\n```\n\nThe adapter must distinguish:\n\n```text\ntest failure         generated tests ran and failed\ntest success         generated tests ran and passed\ninfrastructure error tests could not be generated, started, completed, or evaluated\n```\n\nThe mutator uses that distinction for result classification.\n\n## Gherkin Mutator Command\n\nThe mutator command should expose these options:\n\n```text\ngherkin-mutator [options]\n\nOptions:\n  --feature \u003Cpath>    Gherkin feature file to parse and mutate.\n                      Default: features\u002Fa-feature.feature\n\n  --work-dir \u003Cpath>   Directory where mutation work files are written.\n                      Default: build\u002Facceptance-mutation\n\n  --workers \u003Ccount>   Maximum number of mutation workers to run in parallel.\n                      Values less than 1 must be treated as 1.\n\n  --timeout \u003Cduration>\n                      Timeout for the full acceptance mutation run.\n                      Duration syntax is implementation-defined but should support seconds.\n\n  --status-interval \u003Cduration>\n                      Interval for periodic status lines while mutations are running.\n                      Default: 30s. A value of 0 disables periodic status.\n\n  --level \u003Clevel>     Differential mutation level: full, hard, or soft.\n                      Default: hard.\n\n  --json              Emit JSON report instead of text report.\n```\n\nExit codes:\n\n```text\n0  all mutations were killed and no errors occurred\n1  at least one mutation survived, or at least one mutation produced a setup\u002Ftool error\n2  command-line usage or option parsing error\n```\n\n## Gherkin Example Mutation Model\n\nThe mutator creates candidate mutations from scenario example values. It does not mutate feature names, scenario names, step text, step keywords, background steps, or example headers.\n\nFor each scenario, for each example row, for each example key in lexicographic order:\n\n1. Read the original string value.\n2. Compute the mutated value using the value mutation rules.\n3. If the mutated value is identical to the original value, skip it.\n4. Create one mutation that changes only that single example cell.\n\nThe original JSON IR must not be modified in place. Each mutation is applied to a deep copy of the base IR.\n\n### Mutation Identity\n\nMutation IDs must be stable and deterministic for a fixed input IR:\n\n```text\nm1\nm2\nm3\n...\n```\n\nMutation paths must use this format:\n\n```text\n$.scenarios[\u003Cscenario_index>].examples[\u003Cexample_index>].\u003Ckey>\n```\n\nIndexes are zero-based. Keys are the literal example object keys.\n\nMutation descriptions should use:\n\n```text\n\u003Cpath>: \u003Coriginal> -> \u003Cmutated>\n```\n\n### Value Mutation Rules\n\nValues are strings. The mutator infers a portable value type from the\nstring content, then changes the value without using project-specific\nsemantics. Random choices must be pseudo-random and deterministic for a\nfixed mutation path and original value, so repeated runs over the same IR\nproduce the same mutation set.\n\nBefore selecting a mutation rule, compute:\n\n```text\ntrimmed = value with leading and trailing whitespace removed\n```\n\nRules are applied in this order:\n\n1. If `trimmed` contains a comma, treat it as a comma-delimited list. Split on commas, trim each item, mutate one selected item recursively using these same rules, and join the list with `, `. The selected item must be chosen pseudo-randomly and deterministically.\n2. If lowercase `trimmed` is `true` or `false`, mutate it to the opposite lowercase boolean value.\n3. If lowercase `trimmed` is `null`, `nil`, or `none`, mutate it to a non-empty dithered string.\n4. If `trimmed` is a base-10 integer, mutate it to the decimal representation of the integer plus a pseudo-random nonzero integer delta.\n5. If `trimmed` is a finite base-10 floating point number, mutate it to the decimal representation of the number plus a pseudo-random nonzero floating point delta.\n6. If `trimmed` is an ISO-8601 date, time, or date-time value, mutate it by a pseudo-random nonzero amount appropriate to the represented precision.\n7. If `trimmed` is a recognized duration value, mutate it by a pseudo-random nonzero amount while preserving valid duration syntax.\n8. Otherwise, dither the original untrimmed string.\n\nString dithering must produce a different string by applying one small\nedit, such as inserting a character, deleting a character, replacing a\ncharacter, swapping adjacent characters, or changing character case. Empty\nstrings are dithered by inserting a character.\n\nThe portable mutator must not define command, enum, or domain-specific\nswaps. Project-specific semantic mutations belong in the project adapter\nor in a project-specific mutator extension.\n\nExamples:\n\n```text\n20                  -> 27\n3.14                -> 2.89\ntrue                -> false\n2026-05-13          -> 2026-05-15\n2, 5, 8             -> 2, 11, 8\naccepted            -> accfpted\nmessage with spaces -> message with spcaes\n```\n\n### Equivalent Mutation Filters\n\nProjects may define filters that skip semantically equivalent mutations. Filters are project-specific and belong in the project adapter, not in the portable mutator core.\n\nFilter requirements:\n\n1. Filters must be deterministic.\n2. Filters must run before creating a mutation entry.\n3. The report's `total` count must include only mutations that were executed.\n4. Filtered mutations should not appear in the result list unless the project explicitly adds a separate skipped report.\n\n### Differential Mutation\n\nAcceptance mutation may be run differentially. A differential run reuses previous successful mutation results when it can prove that the relevant feature content and mutation implementation have not changed. Differential mutation is an optimization only; it must not change the meaning of killed, survived, or error results.\n\nThere are two reuse mechanisms:\n\n1. A feature mutation stamp may be used as a whole-file shortcut when the feature has no scenario manifest and the selected level is not `full`. The stamp records a hash of the feature content excluding the stamp line itself. If the stamp is present and valid, the mutator may skip the entire feature and exit successfully.\n2. A scenario manifest may be used for scenario-level reuse. The manifest records enough information to decide which scenarios can be skipped and which scenarios must be rerun.\n\nA feature mutation stamp should use this comment form:\n\n```text\n# mutation-stamp: sha256=\u003Cfeature-content-hash>\n```\n\nThe feature content hash must be computed over the feature file after removing the first mutation-stamp line. A stale, missing, malformed, or mismatched stamp must not be trusted.\n\nA scenario manifest should be stored as a comment block near the top of the feature file:\n\n```text\n# acceptance-mutation-manifest-begin\n# { ... JSON manifest ... }\n# acceptance-mutation-manifest-end\n```\n\nThe JSON manifest must contain:\n\n```json\n{\n  \"version\": 1,\n  \"tested_at\": \"\u003Ctimestamp>\",\n  \"feature_name\": \"\u003Cfeature name>\",\n  \"feature_path\": \"\u003Cfeature path>\",\n  \"background_hash\": \"\u003Chash>\",\n  \"implementation_hash\": \"\u003Chash>\",\n  \"scenarios\": [\n    {\n      \"index\": 0,\n      \"name\": \"\u003Cscenario name>\",\n      \"scenario_hash\": \"\u003Chash>\",\n      \"mutation_count\": 0,\n      \"result\": {\n        \"Total\": 0,\n        \"Killed\": 0,\n        \"Survived\": 0,\n        \"Errors\": 0\n      },\n      \"tested_at\": \"\u003Ctimestamp>\"\n    }\n  ]\n}\n```\n\nThe `background_hash` must cover all background steps, because a background change can affect every scenario. The `scenario_hash` must cover the scenario name, scenario steps, example headers, and example values. Header order must be deterministic. The `implementation_hash` must identify the acceptance mutation implementation and every project adapter component whose behavior can affect mutation generation, filtering, execution, or classification.\n\nWhen a scenario manifest is accepted, a scenario may be skipped only when all of these are true:\n\n1. The manifest version is supported.\n2. The manifest feature name and feature path match the current feature.\n3. The manifest background hash matches the current background hash.\n4. The manifest implementation hash is valid for the selected differential level.\n5. The manifest has an entry for the same scenario index.\n6. The entry scenario name and scenario hash match the current scenario.\n7. The entry has zero survived mutations and zero errors.\n\nSkipped scenarios keep their previous manifest entries, including their previous `tested_at` values. Executed scenarios receive new result summaries and timestamps. Deleted scenarios must be removed from the next manifest. A successful acceptance mutation run should write a fresh scenario manifest and a fresh feature mutation stamp.\n\nDifferential levels:\n\n```text\nfull  ignore stamps and manifests; execute every mutation\nhard  reuse only when feature identity, scenario content, background content,\n      and implementation hash all match\nsoft  reuse when feature identity, scenario content, and background content\n      match, even if the implementation hash changed\n```\n\n`hard` is the default because it avoids reusing results after changes to the parser, generator, mutator, filters, runner adapter, or runtime. `soft` is useful when implementation changes are known not to affect acceptance mutation behavior. `full` is useful for scheduled verification, baseline refreshes, and debugging stale-manifest suspicion.\n\n## Acceptance Mutation Execution\n\nFor each mutation:\n\n1. Create a mutation work directory:\n\n   ```text\n   \u003Cwork-dir>\u002F\u003Cmutation-id>\u002F\n   ```\n\n2. Write the mutated JSON IR to:\n\n   ```text\n   \u003Cwork-dir>\u002F\u003Cmutation-id>\u002Ffeature.json\n   ```\n\n3. Ask the acceptance generator to generate executable tests from that IR.\n\n4. Place generated tests under:\n\n   ```text\n   \u003Cwork-dir>\u002F\u003Cmutation-id>\u002Fgenerated\u002F\n   ```\n\n5. Run the generated tests using the test runner adapter.\n\n6. Classify the result.\n\nParallel workers may execute different mutations concurrently. Each mutation must write only inside its own mutation work directory.\n\nThe timeout applies to the full acceptance mutation run. When the timeout expires, unfinished mutations should be reported as `error` with useful timeout text.\n\nIf differential mutation skips scenarios, the report should include the skipped scenario count and skipped mutation count separately from the executed mutation totals.\n\n## Acceptance Mutation Status\n\nThe mutator should emit periodic status lines while an acceptance mutation run is active, so agents and continuous-integration logs can distinguish a long-running run from a hung process.\n\nStatus lines must be written to standard error. Standard output is reserved for the final text or JSON report, and `--json` output must remain valid JSON without progress records mixed into it.\n\nThe mutator should emit:\n\n1. One status line after mutation discovery and before executing the first mutation.\n2. One status line at least every `--status-interval` while at least one mutation is still running.\n3. One status line when execution finishes, before the final report is emitted.\n\nStatus lines should be single-line, stable, human-readable records using this form:\n\n```text\nstatus elapsed=\u003Cduration> total=\u003Ctotal> completed=\u003Ccompleted> running=\u003Crunning> killed=\u003Ckilled> survived=\u003Csurvived> errors=\u003Cerrors> skipped_scenarios=\u003Ccount> skipped_mutations=\u003Ccount>\n```\n\n`skipped_scenarios` and `skipped_mutations` may be omitted when no differential mutation skip occurred. `completed` counts only executed mutations that have reached `killed`, `survived`, or `error`. `running` counts mutations currently assigned to workers. The final status line should have `running=0` and `completed` equal to the executed mutation total.\n\nThe status interval is best-effort: implementations may delay a status line while synchronously parsing, generating, or waiting for a test runner, but long-running worker orchestration should continue to report progress.\n\n## Result Classification\n\nEach mutation has one of these statuses:\n\n```text\nkilled\nsurvived\nerror\n```\n\nClassification rules:\n\n```text\nkilled   generated tests failed after the mutation was applied\nsurvived generated tests passed after the mutation was applied\nerror    parsing, IR writing, generation, timeout, runner startup, or infrastructure failed\n```\n\nA killed mutation means the acceptance tests detected the changed specification value.\n\nA survived mutation means the acceptance tests did not detect the changed specification value and should be investigated.\n\nAn error is not a test-quality result; it means the mutation could not be evaluated reliably.\n\n## Text Acceptance Mutation Report\n\nThe default text report starts with one summary line:\n\n```text\ntotal=\u003Ctotal> killed=\u003Ckilled> survived=\u003Csurvived> errors=\u003Cerrors>\n```\n\nWhen differential mutation skips scenarios, the report should also include:\n\n```text\nskipped_scenarios=\u003Ccount> skipped_mutations=\u003Ccount>\n```\n\nIt then prints one line per result:\n\n```text\n\u003Cstatus> \u003Cpath>: \u003Coriginal> -> \u003Cmutated>\n```\n\nStatus should be left-aligned to 8 characters for readability.\n\nFor `survived` and `error` results, include available details:\n\n```text\n  error: \u003Cerror text>\n  output:\n\u003Crunner output>\n```\n\nExample:\n\n```text\ntotal=2 killed=1 survived=1 errors=0\nkilled   $.scenarios[0].examples[0].count: 20 -> 27\nsurvived $.scenarios[1].examples[0].status: accepted -> accfpted\n  output:\n\u003Ctest runner output>\n```\n\n## JSON Acceptance Mutation Report\n\nWhen `--json` is supplied, the report must be a JSON object:\n\n```json\n{\n  \"summary\": {\n    \"Total\": 2,\n    \"Killed\": 1,\n    \"Survived\": 1,\n    \"Errors\": 0\n  },\n  \"results\": [\n    {\n      \"Mutation\": {\n        \"ID\": \"m1\",\n        \"Path\": \"$.scenarios[0].examples[0].count\",\n        \"Description\": \"$.scenarios[0].examples[0].count: 20 -> 27\",\n        \"Original\": \"20\",\n        \"Mutated\": \"27\"\n      },\n      \"Status\": \"killed\",\n      \"Output\": \"\u003Ctest runner output>\",\n      \"Error\": \"\",\n      \"Duration\": 125000000\n    }\n  ]\n}\n```\n\nPortable field requirements:\n\n```text\nsummary.Total     number\nsummary.Killed    number\nsummary.Survived  number\nsummary.Errors    number\nsummary.SkippedScenarios  number, when differential mutation skipped scenarios\nsummary.SkippedMutations  number, when differential mutation skipped scenarios\nresults           array\n```\n\nEach result object must include:\n\n```text\nMutation.ID           string\nMutation.Path         string\nMutation.Description  string\nMutation.Original     string\nMutation.Mutated      string\nStatus                \"killed\", \"survived\", or \"error\"\nOutput                string\nError                 string\nDuration              implementation-defined duration value\n```\n\nImplementations may choose idiomatic JSON key casing, but they should document it and keep it stable.\n\n## Agent Setup Checklist\n\nWhen installing this pipeline in a new project, an agent should:\n\n1. Create `features\u002Fa-feature.feature` with at least one scenario that exercises real project behavior.\n2. Implement the Gherkin parser command.\n3. Implement JSON IR reader\u002Fwriter support.\n4. Implement the acceptance runtime that expands scenarios, applies backgrounds, and dispatches steps.\n5. Implement project step handlers for every step text in the feature file.\n6. Implement the acceptance generator command.\n7. Add the normal acceptance script.\n8. Run the normal acceptance script and confirm generated tests pass.\n9. Implement the mutator command using the same parser, IR, generator, and test runner adapter.\n10. Add the acceptance mutation script.\n11. Run the acceptance mutation script and inspect survived mutations.\n12. Add or improve acceptance scenarios until important mutations are killed.\n13. Add parser, generator, runtime, and mutator unit tests.\n14. Add the normal acceptance script to the project's regular verification workflow.\n15. Add the acceptance mutation script to an explicit quality workflow, because acceptance mutation may be slower than normal verification.\n\n## Conformance Checklist\n\nA conforming implementation can be validated with these cases:\n\n1. Parser accepts `Feature:`, `Background:`, `Scenario:`, `Scenario Outline:`, supported steps, parameter placeholders, and examples tables.\n2. Parser writes the JSON IR shape defined in this document.\n3. Parser rejects a file with no feature declaration.\n4. Parser rejects examples outside a scenario.\n5. Parser rejects an examples data row whose cell count differs from the header.\n6. Generator creates deterministic executable tests from JSON IR.\n7. Generated tests execute the IR they were generated from.\n8. Runtime applies background steps before every scenario execution.\n9. Runtime executes scenarios without examples once.\n10. Runtime fails unsupported step text.\n11. Runtime fails invalid or missing example values.\n12. Normal acceptance script fails if parsing, generation, or generated tests fail.\n13. Mutator generates mutations only for example cell values.\n14. Mutator produces stable mutation IDs, paths, and descriptions.\n15. Mutator applies comma-list, boolean, null-like, integer, floating point, date\u002Ftime, duration, and string-dithering value mutation rules.\n16. Mutator deep-copies the IR before applying each mutation.\n17. Mutator classifies failing generated tests as `killed`.\n18. Mutator classifies passing generated tests as `survived`.\n19. Mutator classifies parsing, generation, timeout, and infrastructure failures as `error`.\n20. Mutator exits with `1` when any mutation survives or errors.\n21. Mutator emits text and JSON reports in stable order.\n22. Mutator emits periodic status lines to standard error without corrupting text or JSON reports on standard output.\n23. Mutator supports differential levels `full`, `hard`, and `soft`, with `hard` as the default.\n24. Mutator ignores stamps and manifests at `full` level.\n25. Mutator at `hard` level skips only clean manifest scenarios whose feature identity, background hash, scenario hash, and implementation hash match.\n26. Mutator at `soft` level skips clean manifest scenarios whose feature identity, background hash, and scenario hash match, even when the implementation hash differs.\n27. Mutator rejects stale manifests when the background hash changes, and reruns changed scenarios when their scenario hash changes.\n28. Mutator writes a fresh scenario manifest and feature mutation stamp after a successful acceptance mutation run.\n","该项目定义了一个可移植的验收测试流水线规范，允许代理在新项目中安装使用。其核心功能是将Gherkin特性文件转换为JSON中间表示，生成可执行的验收测试，并运行这些测试以及对Gherkin示例进行验收变异以评估测试与被测应用之间的连接强度。技术上，它采用Go语言实现，但设计为语言和项目中立，适用于多种编程环境。特别适合需要确保自动化测试覆盖度并提高测试可靠性的软件开发场景。",2,"2026-06-11 03:57:15","CREATED_QUERY"]