diff --git a/.opencode/knowledge/requirements/gherkin.md b/.opencode/knowledge/requirements/gherkin.md index 20a6deb..c00e9c6 100644 --- a/.opencode/knowledge/requirements/gherkin.md +++ b/.opencode/knowledge/requirements/gherkin.md @@ -195,5 +195,5 @@ Test path conventions (`tests/features//`), the feature-test vs un - [[requirements/decomposition]]: splitting Rules with too many Examples - [[requirements/pre-mortem]]: finding hidden failure modes in rules - [[software-craft/test-design]]: property-based testing for invariant rules -- [[software-craft/test-stubs]]: how beehave generates test stubs from feature files +- [[software-craft/test-stubs]]: how beehave generates test stubs from feature files, development stage tracking via `beehave status` - [[software-craft/external-fixtures]]: real data fixtures for external adapter mocking diff --git a/.opencode/knowledge/software-craft/source-stubs.md b/.opencode/knowledge/software-craft/source-stubs.md index dd74173..2e97489 100644 --- a/.opencode/knowledge/software-craft/source-stubs.md +++ b/.opencode/knowledge/software-craft/source-stubs.md @@ -13,7 +13,7 @@ last-updated: 2026-05-08 - Source stubs contain the absolute minimum to compile and trace: Protocol signatures with `raise NotImplementedError` bodies, no docstrings, no type hints beyond the contract. - Package structure mirrors the module structure from technical design; the domain package depends on nothing. - Feature branches are created from the latest main. -- Create artifacts in this order: branch, directories, port interfaces, Protocol stubs, run beehave generate to create test stubs, run beehave check. +- Create artifacts in this order: branch, directories, port interfaces, Protocol stubs, run beehave generate to create test stubs, verify with `beehave check` and `beehave status` for development stage confirmation per [[software-craft/test-stubs#concepts]]. ## Concepts diff --git a/.opencode/knowledge/software-craft/test-stubs.md b/.opencode/knowledge/software-craft/test-stubs.md index f4e6e29..4770d30 100644 --- a/.opencode/knowledge/software-craft/test-stubs.md +++ b/.opencode/knowledge/software-craft/test-stubs.md @@ -1,74 +1,73 @@ --- domain: software-craft tags: [test-stubs, traceability, pytest-beehave, scenario-outline, hypothesis] -last-updated: 2026-05-19 +last-updated: 2026-05-20 --- # Test Stubs ## Key Takeaways -- Test stubs are auto-generated by `beehave generate ` from the feature file; no manual stub creation is needed. -- pytest-beehave uses title-based mapping: each Example title becomes a test function named `test_` (e.g., `test_VAT_is_applied_at_the_correct_rate`). -- Structural traceability (every Example has a test, no orphan tests, placeholders present, literals present) is verified by `beehave check`, not manually. -- Scenario Outline produces parameterized stubs with Hypothesis `@given` decorators (inferred strategies) and `@example` decorators (one per Examples table row). Plain Examples produce bare function stubs. -- `beehave check` verifies literal values from steps appear in test function bodies — tests must use the exact quoted strings and numbers from the spec. +- Test stubs are auto-generated by `beehave generate ` from the feature file; no manual stub creation is needed. pytest-beehave uses title-based mapping: each Example title becomes a test function named `test_`. +- `beehave check` verifies structural traceability (every Example has a test, no orphan tests, placeholders present, literals present). Scenario Outline produces parameterized stubs with Hypothesis `@given` decorators (inferred strategies) and `@example` decorators (one per Examples table row). +- Literals from Given/When/Then steps (quoted strings, bare numbers) must appear verbatim in test function bodies — `beehave check` enforces this. Stubs (functions with `...` body) are exempt from literal and placeholder checks. +- `beehave status` reports development stage per feature across 6 stages (ok, broken, needs scenarios, needs tests, needs bodies, needs fixes) with tree or `--json` output. Use `beehave status --json` for project-wide overview and `beehave status` for per-feature tree view including inline violation codes. +- `beehave list` lists feature slugs and titles for features with Examples; `list -v` adds path, scenario count, stub/impl counts. `beehave clean --force` removes unmapped test functions from feature-paired test directories. +- Feature file stem MUST match the Feature title slug (e.g., Feature "CLI Entrypoint" → `cli_entrypoint.feature`). Title violations anywhere in the project block `beehave generate` (pre-flight validates all titles project-wide). `beehave check ` skips global title validation — only `beehave check` (no argument) runs `validate_all_titles`. ## Concepts -**Title-Based Mapping**. pytest-beehave maps each Example or Scenario Outline in the feature file to a test function by title. The function name is derived from the Example or Scenario Outline title as a slug (e.g., Example: "VAT is applied at the correct rate" → `test_vat_is_applied_at_the_correct_rate`). This replaces the previous `@id` tag system. Titles must be unique within a feature file and 2–6 words per [[requirements/gherkin#concepts]]. +**Title-Based Mapping and Auto-Generated Stubs**. pytest-beehave maps each Example or Scenario Outline in the feature file to a test function by title. The function name is derived from the Example or Scenario Outline title as a slug (e.g., Example: "VAT is applied at the correct rate" → `test_vat_is_applied_at_the_correct_rate`). Titles must be unique within a feature file and 2–6 words per [[requirements/gherkin#concepts]]. When `beehave generate ` runs, pytest-beehave reads the feature files and creates test stubs automatically. Each stub has an `...` (Ellipsis) body. During pytest collection, pytest-beehave auto-skips any test function with an `...` body — no `@pytest.mark.skip` decorator is needed. The SE replaces the `...` body with the test implementation during the RED phase. -**Auto-Generated Stubs**. When `beehave generate ` runs, pytest-beehave reads the feature files and creates test stubs automatically. Each stub has an `...` (Ellipsis) body. During pytest collection, pytest-beehave auto-skips any test function with an `...` body — no `@pytest.mark.skip` decorator is needed. The SE replaces the `...` body with the test implementation during the RED phase. +**Traceability Verification and Scenario Outline Stubs**. `beehave check` enforces structural traceability with 6 violation types: `unmapped-scenario` (Example with no test), `unmapped-test` (test with no Example), `misplaced-test` (test in wrong file), `missing-placeholder` (placeholder not in test body), `missing-literal` (literal not in test body), `example-mismatch` (Examples table row lacking `@example()` decorator). Scenario Outline stubs include `@given(placeholder_name=strategy)` decorators with inferred Hypothesis strategies plus `@example()` for each Examples table row. Strategy is inferred from column values: all integers → `st.integers()`, all floats → `st.floats()`, all booleans → `st.booleans()`, otherwise `st.text()`. Override by defining a strategy variable in the test file. -**Scenario Outline Stubs**. When a feature uses `Scenario Outline:` with `` syntax, the generated stub includes: -- `@given(placeholder_name=st.text())` (or inferred strategy) for each placeholder -- `@example(col1="val1", col2="val2")` for each row in the Examples table -- Function parameters matching placeholder names +**Literal and Placeholder Verification**. `beehave check` extracts quoted strings (`"value"`) and bare numbers (`42`, `-3`) from Given/When/Then steps and verifies they appear in the test function body. Per Spec Value Fidelity ([[software-craft/test-design#concepts]]), every literal and placeholder must carry domain meaning in the test — identifiers identify entities, boundaries bound, configurations configure. Never satisfy traceability with noise: assigning to `_`, stuffing strings into assert messages, or helper functions whose sole purpose is consuming a literal. Placeholder names become Python function parameters and must be valid Python identifiers (not keywords, not builtins like `sum`, `list`). -Example stub generated from a Scenario Outline: +**Development Stage Tracking with beehave status**. `beehave status` computes a development stage for each feature file. JSON output (`--json`) provides per-feature stages, per-scenario status with violation types, summary counts, `unmapped_directories`, and `collisions`. Tree output shows Rule → Scenario hierarchy with inline violation codes. `--include-unmapped` finds orphan test directories. A feature is `ok` even with mixed stubs and implementations — `needs bodies` fires only when ALL scenarios are stubs. -```python -from hypothesis import example, given, strategies as st +**Project Overview with beehave list and Cleanup with beehave clean**. `beehave list` shows feature slugs and titles for features with at least one Example. `beehave list -v` adds: path, scenario count (total + top-level vs rule breakdown), stub/impl counts (e.g., "stubs: 1/2 (1 implemented)"). `beehave clean [--force]` removes unmapped test functions from that feature's test directory and reports what was removed. -@given(qty=st.integers()) -@example(qty=1) -@example(qty=5) -@example(qty=100) -def test_quantity_rejected_when_negative(qty): - ... -``` +**Feature File Stem and Title Consistency**. The feature filename stem MUST match the Feature title slug. Feature "CLI Entrypoint" (slug `cli_entrypoint`) → file `cli_entrypoint.feature` → test directory `tests/features/cli_entrypoint/`. Mismatch causes unmapped directories and test mapping failures. `beehave generate` runs a project-wide `validate_all_titles` pre-flight that blocks all generation if ANY feature has bad titles. `beehave check ` skips global title validation — only `beehave check` with no argument runs `validate_all_titles`. When a Gherkin parse error exists, `validate_all_titles` raises an exception rather than handling gracefully. -The Hypothesis strategy is inferred from Examples table column values: all integers → `st.integers()`, all floats → `st.floats()`, all booleans → `st.booleans()`, otherwise `st.text()`. To use a custom strategy, define a variable with the placeholder name in the test file before the function. +## Content -**Literal Verification**. `beehave check` extracts quoted strings (`"value"`) and bare numbers (`42`, `-3`) from Given/When/Then steps and verifies they appear in the test function body. This means the test implementation MUST use the exact literal values from the spec — no paraphrasing. For example, if the step says `Then the output contains "temple8"`, the test body must contain the string `"temple8"`. +### Development Stages (beehave status) -**Strategy Inference from Examples Table**. When Scenario Outline has an Examples table, beehave infers Hypothesis strategies per [[requirements/gherkin#concepts]]: +| Stage | Condition | +|-------|-----------| +| `ok` | All Examples have implemented tests with no violations | +| `broken` | Feature file has Gherkin parse errors | +| `needs scenarios` | Has Rules but no Examples | +| `needs tests` | Has Examples but some lack test functions | +| `needs bodies` | All Examples have test functions but all bodies are `...` stubs | +| `needs fixes` | Tests exist with bodies but have violations (missing literals, missing placeholders, example mismatch, etc.) | -| Column Values | Inferred Strategy | -|---------------|-------------------| -| All integers (e.g. `1`, `5`, `100`) | `st.integers()` | -| All floats (e.g. `1.0`, `3.14`) | `st.floats()` | -| All booleans (`true`, `false`) | `st.booleans()` | -| Mixed or text (e.g. `Widget`, `Gadget`) | `st.text()` | +### beehave status --json Structure -Override by defining a variable with the placeholder name as a Hypothesis strategy in the test file. +| Key | Content | +|-----|---------| +| `features` | Per-feature: `slug`, `stage`, `scenarios[]` with `title`, `status`, `violations[]` | +| `summary` | Counts per stage: `ok`, `broken`, `needs_scenarios`, `needs_tests`, `needs_bodies`, `needs_fixes` | +| `unmapped_directories` | Test directories with no matching feature file | +| `collisions` | Test function names appearing in multiple feature test dirs | -**beehave check**. The `beehave check` command (from the `beehave` library, not to be confused with the `behave` BDD framework) verifies structural traceability. It enforces: +### beehave list -v Output -| Violation Type | What It Detects | -|----------------|-----------------| -| `unmapped-scenario` | Example/Scenario Outline in .feature with no test function (note: "scenario" in the beehave error name refers to Examples) | -| `unmapped-test` | Test function with no matching Example/Scenario Outline | -| `misplaced-test` | Test in wrong file (rule path mismatch) | -| `missing-placeholder` | Placeholder `` from step not used in test body | -| `missing-literal` | Literal value from step not found in test body | -| `example-mismatch` | Examples table row has no matching `@example()` decorator | +| Field | Description | +|-------|-------------| +| `slug` | Feature title slugified | +| `title` | Feature title | +| `path` | Path to the .feature file | +| `scenarios` | Total scenario count | +| `top_level_scenarios` | Scenarios not under a Rule | +| `rules` | Count of Rule blocks | +| `rule_scenarios` | Scenarios under Rules | +| `stubs` | Stub count (including `...` body count) | +| `implemented` | Implemented scenario count | -Stubs (functions with `...` body) are exempt from placeholder and literal checks — these only apply once the `...` is replaced with implementation. +### Test File Layout -**Test File Layout**. pytest-beehave organizes tests as: Feature title → directory, Rule → test file, Example/Scenario Outline → function name. Test files are placed in `tests/features//_test.py`. - -**Spec Value Fidelity in Tests**. Every literal and placeholder from the spec must appear in the test body — `beehave check` verifies this. Per Spec Value Fidelity ([[software-craft/test-design#concepts]]), the test must use each value in a way that reflects its domain purpose. If `"BTC/USD"` represents a trading pair, use it to construct or identify one. If `42` is a boundary value, use it at the boundary. Never satisfy traceability with noise: assigning to `_`, stuffing strings into assert messages, or writing helper functions whose sole purpose is consuming a literal. These mask the real issue — the value's domain purpose is not reflected in the test. +pytest-beehave organizes tests as: Feature title → directory, Rule → test file, Example/Scenario Outline → function name. Test files are placed in `tests/features//_test.py`. ## Related diff --git a/.opencode/skills/accept-feature/SKILL.md b/.opencode/skills/accept-feature/SKILL.md index 48190e1..d89b8f9 100644 --- a/.opencode/skills/accept-feature/SKILL.md +++ b/.opencode/skills/accept-feature/SKILL.md @@ -5,12 +5,12 @@ description: "Validate business behavior against BDD examples from the end user' # Accept Feature -Available knowledge: [[requirements/gherkin#key-takeaways]], [[software-craft/test-design#key-takeaways]]. `in` artifacts: read all before starting work. +Available knowledge: [[requirements/gherkin#key-takeaways]], [[software-craft/test-design#key-takeaways]], [[software-craft/test-stubs#concepts]]. `in` artifacts: read all before starting work. 1. Run `task test-build` to verify all tests pass with coverage. 2. Verify all BDD examples pass from the end user's perspective, not the test harness, per [[software-craft/test-design#key-takeaways]]. 3. IF an example passes in the test harness but fails from the user's perspective → flag it as a semantic alignment gap per [[software-craft/test-design#concepts]]. -4. Verify structural traceability via `beehave check`: every Example in the feature file must have exactly one corresponding test function, and every test function must trace back to an Example. pytest-beehave enforces this via title-based mapping. Any violations reported by `beehave check` mean the feature is not done. +4. Verify structural traceability: run `beehave status --json` for stage overview, then `beehave check` for detailed violations per [[software-craft/test-stubs#concepts]]. Every Example in the feature file must have exactly one corresponding test function, and every test function must trace back to an Example. The feature stage must be `ok` and `beehave check` must produce no output. 5. Verify semantic depth per [[software-craft/test-design#concepts]]. 6. Verify quality attributes are met. 7. Verify definition of done criteria are satisfied. diff --git a/.opencode/skills/review-gate/SKILL.md b/.opencode/skills/review-gate/SKILL.md index 8b112e2..304d1ec 100644 --- a/.opencode/skills/review-gate/SKILL.md +++ b/.opencode/skills/review-gate/SKILL.md @@ -5,7 +5,7 @@ description: "Two-tier review with fail-fast: design -> structure" # Review Gate -Available knowledge: [[software-craft/code-review]], [[software-craft/test-design]], [[software-craft/smell-catalogue]], [[architecture/reconciliation#key-takeaways]]. `in` artifacts: read all before starting work. +Available knowledge: [[software-craft/code-review]], [[software-craft/test-design]], [[software-craft/test-stubs]], [[software-craft/smell-catalogue]], [[architecture/reconciliation#key-takeaways]]. `in` artifacts: read all before starting work. **Fail-fast rule**: Stop at first failure in any tier. Do NOT proceed to next tier if current tier fails. diff --git a/.opencode/skills/select-feature/SKILL.md b/.opencode/skills/select-feature/SKILL.md index 45c7386..1b2d2f0 100644 --- a/.opencode/skills/select-feature/SKILL.md +++ b/.opencode/skills/select-feature/SKILL.md @@ -5,24 +5,16 @@ description: "Select the next feature to develop by detecting delivery status fr # Select Feature -Available knowledge: [[requirements/wsjf#key-takeaways]]. `in` artifacts: read all before starting work. +Available knowledge: [[requirements/wsjf#key-takeaways]], [[software-craft/test-stubs#key-takeaways]]. `in` artifacts: read all before starting work. 1. List available feature files in `docs/features/`. 2. IF no feature files exist → exit via `no-features`; features need discovery first. -3. For each feature, determine delivery status — do NOT open or read individual feature or test files: - - a. Check if the feature file has Example blocks (any line starting with `Example:`). - If none, the feature has not been broken down into BDD examples yet → feature is incomplete. - - b. Run `beehave check ` to verify structural traceability: - - Any output (errors) → some Examples lack matching test functions or there are orphan tests → feature is incomplete. - - No output (clean) → all Examples have matching test functions. - - c. If beehave check is clean, run `task test-fast` scoped to that feature's test directory. - - Any failures → feature is incomplete. - - All pass → feature is delivered (skip). - - d. If the test directory does not exist, beehave check will report errors → feature is incomplete. +3. Run `beehave status --json` for project-wide overview per [[software-craft/test-stubs#concepts]]. For each feature, determine delivery status from its stage: + - Any stage other than `ok` → feature is incomplete. + - Stage `ok` → all Examples have implemented tests with no structural violations, but functional correctness must still be verified. + For features at `ok` stage, run `task test-fast` scoped to that feature's test directory: + - Any failures → feature is incomplete. + - All pass → feature is delivered (skip). 4. IF every feature is delivered → exit via `no-features`. 5. Collect all incomplete features. Derive dependency count for each from `domain_spec.md` context map: diff --git a/.opencode/skills/verify-traceability/SKILL.md b/.opencode/skills/verify-traceability/SKILL.md index 20c86c4..776e99e 100644 --- a/.opencode/skills/verify-traceability/SKILL.md +++ b/.opencode/skills/verify-traceability/SKILL.md @@ -5,7 +5,7 @@ description: "Verify example-to-test traceability via beehave check and semantic # Verify Traceability -Available knowledge: [[software-craft/test-design#key-takeaways]], [[requirements/gherkin#key-takeaways]]. `in` artifacts: read all before starting work. +Available knowledge: [[software-craft/test-design#key-takeaways]], [[requirements/gherkin#key-takeaways]], [[software-craft/test-stubs#concepts]]. `in` artifacts: read all before starting work. -1. Run `beehave check` and verify all violations resolved per [[software-craft/test-stubs#concepts]]. +1. Run `beehave check` and verify all violations resolved per [[software-craft/test-stubs#concepts]]. Optionally use `beehave status --json` for a summary view of the feature's development stage. 2. Verify semantic depth per [[software-craft/test-design#concepts]]: for each Example that describes a user-facing command or API invocation, verify the corresponding test exercises the entry point described in the acceptance criterion (e.g., command handler, API endpoint), not just the domain logic in isolation. A test that calls domain methods directly when the AC describes a user-facing command is a semantic alignment gap: it has structural traceability but wrong semantic depth. diff --git a/CHANGELOG.md b/CHANGELOG.md index 798442b..c8c3408 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,22 @@ All notable changes to this template will be documented in this file. +## [v9.1.0] - 2026-05-20: beehave 1.0.0 Knowledge Integration + +### Added + +- **`[dependency-groups]`**: added `flowr>=1.0.0` to dev dependency group (PEP 735). + +### Changed + +- **`test-stubs.md` (software-craft)**: full rewrite incorporating beehave 1.0.0 features — `beehave status` (6 development stages, `--json`, `--include-unmapped`), `beehave list`/`list -v`, `beehave clean`, collision detection, feature stem = title slug requirement, and behavioral notes (validate_all_titles crash, generate pre-flight scope, single-feature check skip). Added `## Content` section with reference tables. +- **`select-feature/SKILL.md`**: replaced manual per-feature checking with `beehave status --json` for project-wide development stage overview. Added `[[software-craft/test-stubs#key-takeaways]]` to available knowledge. +- **`accept-feature/SKILL.md`**: added `beehave status --json` as pre-check before `beehave check`. Added `[[software-craft/test-stubs#concepts]]` to available knowledge. +- **`verify-traceability/SKILL.md`**: added optional `beehave status --json` summary view. Added `[[software-craft/test-stubs#concepts]]` to available knowledge. +- **`review-gate/SKILL.md`**: added `[[software-craft/test-stubs]]` to available knowledge for consistency. +- **`source-stubs.md` (software-craft)**: updated creation order to include `beehave status` for development stage confirmation. +- **`gherkin.md` (requirements)**: updated Related link to reference `beehave status` for development stage tracking. + ## [v9.0.0+20260518] - 2026-05-18: Adversarial Audit ### Breaking diff --git a/pyproject.toml b/pyproject.toml index 7bf3e25..e2e733f 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "temple8" -version = "9.0.1" +version = "9.1.0" description = "Spec-driven agent orchestration template with YAML flow definitions, multi-agent dispatch, and BDD traceability" readme = "README.md" requires-python = ">=3.14" @@ -32,8 +32,8 @@ dev = [ "pyright>=1.1.407", "ghp-import>=2.1.0", "flowr>=1.0.0", - "beehave>=0.4.0", - "pytest-beehave>=0.2.2", + "beehave>=1.0.0", + "pytest-beehave>=1.0.0", "safety>=3.7.0", ] @@ -50,6 +50,11 @@ tests_dir = "tests/features" [tool.setuptools] packages = ["app"] +[dependency-groups] +dev = [ + "flowr>=1.0.0", +] + [tool.ruff.lint] ignore = [] select = [ diff --git a/uv.lock b/uv.lock index 3b6a673..e3e0a4e 100644 --- a/uv.lock +++ b/uv.lock @@ -47,14 +47,14 @@ wheels = [ [[package]] name = "beehave" -version = "0.4.0" +version = "1.0.0" source = { registry = "https://pypi.org/simple" } dependencies = [ { name = "gherkin-official" }, ] -sdist = { url = "https://files.pythonhosted.org/packages/0c/7e/b64d1cd39f6e6a25479b616ed3bdc9d62f9cd7e52555c4c3960498763c8d/beehave-0.4.0.tar.gz", hash = "sha256:f0a17b4964b6d8f38f1a378032bf942edd31c364a8c3ca74f6a871e46ab40275", size = 55081, upload-time = "2026-05-13T15:53:02.276Z" } +sdist = { url = "https://files.pythonhosted.org/packages/77/01/9b90dec3e14a429b3a54fc69715152b3ca9b34bc5dc9852763d97487f27b/beehave-1.0.0.tar.gz", hash = "sha256:59e959959a0fa7a0e487b6bef4a2af8b9abcad55381e02bbfe11d2433d5aec42", size = 110601, upload-time = "2026-05-20T19:22:02.357Z" } wheels = [ - { url = "https://files.pythonhosted.org/packages/2a/fa/b00734b18ff765b412b1021c7eca9bdf38f30eaeac81b0005c675140edf6/beehave-0.4.0-py3-none-any.whl", hash = "sha256:c2a0335671a4f865c1fdad1e5e7511297faf0f1d2a93dc14c0ea83461f323616", size = 17187, upload-time = "2026-05-13T15:53:00.404Z" }, + { url = "https://files.pythonhosted.org/packages/67/55/1ce4d584ba4e50a8dfcfafb1d27c3e61d17af5cc304ba3705b80a7ceb021/beehave-1.0.0-py3-none-any.whl", hash = "sha256:8ecc505d5a53d48cdb44fa28f67ff5b39840debe8df3733bc71b6470b3325054", size = 25557, upload-time = "2026-05-20T19:22:01.018Z" }, ] [[package]] @@ -665,14 +665,14 @@ wheels = [ [[package]] name = "pytest-beehave" -version = "0.2.2" +version = "1.0.0" source = { registry = "https://pypi.org/simple" } dependencies = [ { name = "beehave" }, ] -sdist = { url = "https://files.pythonhosted.org/packages/c3/ea/6ac241d175e595f79403a4d1d8b8413c3cfb21dedfe81e6cd29a7d5b854c/pytest_beehave-0.2.2.tar.gz", hash = "sha256:e90a165c8b6853c545bbea971536ff4c81710623fe89bc0cd3e4f7c29a5f3406", size = 12896, upload-time = "2026-05-13T18:53:27.801Z" } +sdist = { url = "https://files.pythonhosted.org/packages/85/29/5137c2909394ae2933e5be6aa034a7584c9e7e66b7731e46042408f7e6e4/pytest_beehave-1.0.0.tar.gz", hash = "sha256:e2d745027a58619a06568b3bdb2f88986be6bb4a863e2c5c6fe1a2824cdf2c71", size = 13324, upload-time = "2026-05-20T20:15:11.988Z" } wheels = [ - { url = "https://files.pythonhosted.org/packages/cd/56/3d3cc2130d8cf800be084549f7c32351cb3ea5817ca865dae4098bee7fec/pytest_beehave-0.2.2-py3-none-any.whl", hash = "sha256:f0e9ab4bb5cc3d0abf5ad52d553b3762f42172db89fae40425bfb6882147ea12", size = 9973, upload-time = "2026-05-13T18:53:26.618Z" }, + { url = "https://files.pythonhosted.org/packages/8d/60/6c0e9ca196f6634a0cc1654b6ea0f46e41269ad3b5868ceae241ed901e20/pytest_beehave-1.0.0-py3-none-any.whl", hash = "sha256:2cbcfdf44fc6f328590e324901388731596f0d4c2ab402a593a79363e6b1bd8d", size = 10183, upload-time = "2026-05-20T20:15:10.272Z" }, ] [[package]] @@ -955,7 +955,7 @@ wheels = [ [[package]] name = "temple8" -version = "9.0.1" +version = "9.1.0" source = { virtual = "." } [package.optional-dependencies] @@ -976,16 +976,21 @@ dev = [ { name = "taskipy" }, ] +[package.dev-dependencies] +dev = [ + { name = "flowr" }, +] + [package.metadata] requires-dist = [ - { name = "beehave", marker = "extra == 'dev'", specifier = ">=0.4.0" }, + { name = "beehave", marker = "extra == 'dev'", specifier = ">=1.0.0" }, { name = "flowr", marker = "extra == 'dev'", specifier = ">=1.0.0" }, { name = "ghp-import", marker = "extra == 'dev'", specifier = ">=2.1.0" }, { name = "hypothesis", marker = "extra == 'dev'", specifier = ">=6.148.4" }, { name = "pdoc", marker = "extra == 'dev'", specifier = ">=14.0" }, { name = "pyright", marker = "extra == 'dev'", specifier = ">=1.1.407" }, { name = "pytest", marker = "extra == 'dev'", specifier = ">=9.0.3" }, - { name = "pytest-beehave", marker = "extra == 'dev'", specifier = ">=0.2.2" }, + { name = "pytest-beehave", marker = "extra == 'dev'", specifier = ">=1.0.0" }, { name = "pytest-cov", marker = "extra == 'dev'", specifier = ">=6.1.1" }, { name = "pytest-html", marker = "extra == 'dev'", specifier = ">=4.0.0" }, { name = "pytest-mock", marker = "extra == 'dev'", specifier = ">=3.14.0" }, @@ -995,6 +1000,9 @@ requires-dist = [ ] provides-extras = ["dev"] +[package.metadata.requires-dev] +dev = [{ name = "flowr", specifier = ">=1.0.0" }] + [[package]] name = "tenacity" version = "9.1.4"