From b4626864246c1ba1ecee8d2f90851d46269fa76a Mon Sep 17 00:00:00 2001 From: nullhack Date: Tue, 19 May 2026 22:55:43 -0400 Subject: [PATCH] =?UTF-8?q?fix:=20consistency=20audit=20=E2=80=94=20featur?= =?UTF-8?q?e=5Ftitle=20convention,=20git:dev=20references,=20stale=20exits?= =?UTF-8?q?,=20agent=20ownership,=20beehave=20status=20gates,=207-principl?= =?UTF-8?q?e=20review?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Rename feature_id → feature_title everywhere: flow YAMLs, skills, knowledge, AGENTS.md, CHANGELOG.md, templates - Bump flowr 1.0.0 → 1.1.0 (pyproject.toml, uv.lock) - review-gate: split step 5 into 7 sub-steps (YAGNI, KISS, DRY, ObjCal, Smells, SOLID, Patterns) matching tdd-cycle exit conditions - verify-traceability: make beehave status --json mandatory gate (stage ok → skip beehave check) - review-gate tier 2: add beehave status --json as pre-check before beehave check - refactor: add explicit knowledge references for all 7 design principles - SE agent: ownership/noqa/pyproject identity statement - implement-minimum: fix existing test/beehave failures in touched files - polish-code: fix all violations codebase-wide - write-test: anti-noise rules for Spec Value Fidelity - Flow YAML: remove unreachable exits (cancelled, needs-reinterview), add params to define-flow - Templates: new test stub template, rename feature_name → feature_title - Remove stale @id references from AGENTS.md, README.md, docs/audit/ --- .flowr/flows/define-flow.yaml | 4 ++-- .flowr/flows/deliver-flow.yaml | 8 ++++---- .flowr/flows/develop-flow.yaml | 19 +++++++++---------- .flowr/flows/development-flow.yaml | 10 +++++----- .flowr/flows/tdd-cycle-flow.yaml | 8 ++++---- .opencode/agents/software-engineer.md | 3 ++- .../architecture/technical-design.md | 2 +- .../knowledge/software-craft/source-stubs.md | 2 +- .../knowledge/software-craft/test-stubs.md | 4 ++-- .opencode/skills/create-py-stubs/SKILL.md | 2 +- .opencode/skills/implement-minimum/SKILL.md | 2 +- .opencode/skills/polish-code/SKILL.md | 2 +- .opencode/skills/refactor/SKILL.md | 4 ++-- .opencode/skills/review-gate/SKILL.md | 14 +++++++++++--- .opencode/skills/select-feature/SKILL.md | 2 +- .opencode/skills/setup-apply/SKILL.md | 2 +- .opencode/skills/simulate-spec/SKILL.md | 2 +- .opencode/skills/verify-traceability/SKILL.md | 2 +- .opencode/skills/write-bdd-features/SKILL.md | 2 +- .opencode/skills/write-test/SKILL.md | 2 +- ...plate => .feature.template} | 0 .../features/_test.py.template | 12 ++++++++++++ AGENTS.md | 18 +++++++++--------- CHANGELOG.md | 2 +- README.md | 2 +- docs/audit/document-landscape-audit.md | 4 ++-- pyproject.toml | 4 ++-- uv.lock | 10 +++++----- 28 files changed, 84 insertions(+), 64 deletions(-) rename .templates/docs/features/{.feature.template => .feature.template} (100%) create mode 100644 .templates/tests/features/_test.py.template diff --git a/.flowr/flows/define-flow.yaml b/.flowr/flows/define-flow.yaml index 9784845..612f26d 100644 --- a/.flowr/flows/define-flow.yaml +++ b/.flowr/flows/define-flow.yaml @@ -1,8 +1,8 @@ flow: define-flow version: 2.0.0 +params: [feature_title] exits: - validated - - needs-reinterview states: - id: discovery @@ -37,7 +37,7 @@ states: - glossary.md - "features/*.feature" out: - - "features/.feature": + - "features/.feature": - feature_header - constraints - rules diff --git a/.flowr/flows/deliver-flow.yaml b/.flowr/flows/deliver-flow.yaml index 6128454..d6f791e 100644 --- a/.flowr/flows/deliver-flow.yaml +++ b/.flowr/flows/deliver-flow.yaml @@ -1,6 +1,6 @@ flow: deliver-flow version: 1.0.0 -params: [feature_id] +params: [feature_title] exits: - published - accumulate @@ -16,8 +16,8 @@ states: skills: - merge-local in: - - ".cache/acceptance/.md" - - features/.feature + - ".cache/acceptance/.md" + - features/.feature out: - merged-commits next: @@ -47,7 +47,7 @@ states: - create-pr in: - merged-commits - - features/.feature + - features/.feature out: [] conditions: merged: diff --git a/.flowr/flows/develop-flow.yaml b/.flowr/flows/develop-flow.yaml index 03d51c8..0c8d698 100644 --- a/.flowr/flows/develop-flow.yaml +++ b/.flowr/flows/develop-flow.yaml @@ -1,10 +1,9 @@ flow: develop-flow version: 2.0.0 -params: [feature_id] +params: [feature_title] exits: - completed - needs-architecture - - cancelled states: - id: feature-selection @@ -17,7 +16,7 @@ states: in: - product_definition.md - domain_spec.md - - "features/.feature" + - "features/.feature" out: [] next: selected: feature-examples @@ -32,12 +31,12 @@ states: skills: - write-bdd-features in: - - features/.feature + - features/.feature - product_definition.md - domain_spec.md - glossary.md out: - - features/.feature: + - features/.feature: - examples conditions: examples-complete: @@ -55,7 +54,7 @@ states: skills: - review-spec in: - - features/.feature + - features/.feature - product_definition.md - domain_spec.md - glossary.md @@ -87,13 +86,13 @@ states: - accept-feature - verify-traceability in: - - features/.feature + - features/.feature - product_definition.md - domain_spec.md - glossary.md - ".cache/interview-notes/*.md" out: - - ".cache/acceptance/.md" + - ".cache/acceptance/.md" conditions: feature-accepted: acceptance-verified: ==verified @@ -113,7 +112,7 @@ states: in: - source-implementations - test-implementations - - features/.feature + - features/.feature out: - polished-source next: @@ -129,7 +128,7 @@ states: in: - polished-source - test-implementations - - features/.feature + - features/.feature out: - feature-commits conditions: diff --git a/.flowr/flows/development-flow.yaml b/.flowr/flows/development-flow.yaml index c91bc72..e2e960e 100644 --- a/.flowr/flows/development-flow.yaml +++ b/.flowr/flows/development-flow.yaml @@ -1,6 +1,6 @@ flow: development-flow version: 13.0.0 -params: [feature_id] +params: [feature_title] exits: - done @@ -13,7 +13,7 @@ states: skills: - structure-feature in: - - features/.feature + - features/.feature - domain_spec.md - glossary.md - product_definition.md @@ -30,7 +30,7 @@ states: skills: - create-py-stubs in: - - features/.feature + - features/.feature - domain_spec.md - glossary.md - product_definition.md @@ -86,7 +86,7 @@ states: in: - test-implementations - source-implementations - - features/.feature + - features/.feature - domain_spec.md - "adr/*.md" # optional out: [] @@ -104,7 +104,7 @@ states: in: - source-implementations - test-implementations - - features/.feature + - features/.feature out: - feature-commits conditions: diff --git a/.flowr/flows/tdd-cycle-flow.yaml b/.flowr/flows/tdd-cycle-flow.yaml index f7b4fd4..f58a987 100644 --- a/.flowr/flows/tdd-cycle-flow.yaml +++ b/.flowr/flows/tdd-cycle-flow.yaml @@ -1,6 +1,6 @@ flow: tdd-cycle-flow version: 8.0.0 -params: [feature_id] +params: [feature_title] exits: - all-green @@ -15,7 +15,7 @@ states: in: - test-skeletons - typed-source-stubs - - features/.feature + - features/.feature - domain_spec.md - glossary.md out: @@ -33,7 +33,7 @@ states: in: - test-implementations - typed-source-stubs - - features/.feature + - features/.feature - domain_spec.md - glossary.md out: @@ -51,7 +51,7 @@ states: in: - source-implementations - test-implementations - - features/.feature + - features/.feature - domain_spec.md - glossary.md out: diff --git a/.opencode/agents/software-engineer.md b/.opencode/agents/software-engineer.md index db9d463..984f7cd 100644 --- a/.opencode/agents/software-engineer.md +++ b/.opencode/agents/software-engineer.md @@ -7,4 +7,5 @@ temperature: 0.3 # Software Engineer You are the Software Engineer. You write production code that passes tests and meets acceptance criteria. -You are responsible for implementation, TDD cycles, commits, and merge operations. \ No newline at end of file +You are responsible for implementation, TDD cycles, commits, and merge operations. +You own every file you modify. When you encounter an existing issue — a convention violation, a beehave check failure, a lint error — you fix it regardless of who introduced it. You never use `noqa`. You never change `pyproject.toml`. In legitimate cases when you cannot proceed with these restrictions, ask the stakeholder what to do and explain the issue. \ No newline at end of file diff --git a/.opencode/knowledge/architecture/technical-design.md b/.opencode/knowledge/architecture/technical-design.md index 62d67ce..ff0b430 100644 --- a/.opencode/knowledge/architecture/technical-design.md +++ b/.opencode/knowledge/architecture/technical-design.md @@ -41,7 +41,7 @@ Hybrid approaches are valid: a monolith with hexagonal internals, or microservic ### Module Structure Template ``` -feature_name/ +feature_title/ domain/ # Business logic, zero infrastructure imports application/ # Use case orchestration infrastructure/ # External concerns (DB, HTTP, queues) diff --git a/.opencode/knowledge/software-craft/source-stubs.md b/.opencode/knowledge/software-craft/source-stubs.md index 2e97489..a36e81c 100644 --- a/.opencode/knowledge/software-craft/source-stubs.md +++ b/.opencode/knowledge/software-craft/source-stubs.md @@ -27,7 +27,7 @@ last-updated: 2026-05-08 **Branch Setup**. Implementation begins on a feature branch (`feat/`) created from the latest main. Branch naming follows [[software-craft/git-conventions]]. -**Creation Order**. Create artifacts in this order: (1) feature branch from main, (2) package directories from module structure, (3) port interfaces and aggregate root signatures, (4) per-feature: Protocol stubs from contracts + run `beehave generate ` to create test stubs per [[software-craft/test-stubs#key-takeaways]], (5) run `beehave check` to verify all Examples have corresponding test stubs. +**Creation Order**. Create artifacts in this order: (1) feature branch from main, (2) package directories from module structure, (3) port interfaces and aggregate root signatures, (4) per-feature: Protocol stubs from contracts + run `beehave generate ` to create test stubs per [[software-craft/test-stubs#key-takeaways]], (5) run `beehave check` to verify all Examples have corresponding test stubs. ## Related diff --git a/.opencode/knowledge/software-craft/test-stubs.md b/.opencode/knowledge/software-craft/test-stubs.md index 4770d30..9a19703 100644 --- a/.opencode/knowledge/software-craft/test-stubs.md +++ b/.opencode/knowledge/software-craft/test-stubs.md @@ -8,7 +8,7 @@ last-updated: 2026-05-20 ## 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_`. +- 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. @@ -17,7 +17,7 @@ last-updated: 2026-05-20 ## 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. +**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. **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. diff --git a/.opencode/skills/create-py-stubs/SKILL.md b/.opencode/skills/create-py-stubs/SKILL.md index e11fc85..a192550 100644 --- a/.opencode/skills/create-py-stubs/SKILL.md +++ b/.opencode/skills/create-py-stubs/SKILL.md @@ -9,7 +9,7 @@ Available knowledge: [[architecture/technical-design]], [[software-craft/source- 1. Read the feature file and identify the domain entities, value objects, and use cases referenced by the Examples and Scenario Outlines. 2. For each referenced entity/value object/use case not yet implemented, create a minimal typed stub per [[software-craft/source-stubs#concepts]]: Protocol method signatures with `raise NotImplementedError` bodies, no docstrings, no type hints beyond the contract. These stubs are breadcrumbs from the domain spec. The SE can add, remove, or modify them during implementation. -3. Run `beehave generate ` to generate test stubs from the feature file per [[software-craft/test-stubs#concepts]]: +3. Run `beehave generate ` to generate test stubs from the feature file per [[software-craft/test-stubs#concepts]]: - Plain Examples → bare function stubs with `...` body - Scenario Outlines → `@given` decorated stubs with inferred Hypothesis strategies + `@example` decorators for each Examples table row - Placeholder names become function parameters; strategy is inferred from Examples table column types diff --git a/.opencode/skills/implement-minimum/SKILL.md b/.opencode/skills/implement-minimum/SKILL.md index 139f3d5..cb603e6 100644 --- a/.opencode/skills/implement-minimum/SKILL.md +++ b/.opencode/skills/implement-minimum/SKILL.md @@ -7,6 +7,6 @@ description: "Write the minimum production code needed to make the failing test Available knowledge: [[software-craft/tdd]], [[software-craft/test-design]], [[software-craft/smell-catalogue]], [[software-craft/object-calisthenics]], [[software-craft/solid]]. `in` artifacts: read all before starting work. -1. Write the minimum code to make the failing test pass AND satisfy reviewer checks per [[software-craft/tdd#key-takeaways]]. Add docstrings, type hints, and lint compliance only when reviewers require them, not proactively. +1. Write the minimum code to make the failing test pass AND satisfy reviewer checks per [[software-craft/tdd#key-takeaways]]. Add docstrings, type hints, and lint compliance only when reviewers require them, not proactively. Fix any existing test failures or beehave violations in files you touch. Never use `noqa` — find and fix the root cause. Never change `pyproject.toml`. 2. IF a spec gap or inconsistency is discovered during implementation → do NOT modify specification documents (domain_spec.md, glossary.md, product_definition.md, ADRs, feature files). These are owned by other flow states. Flag the gap in output notes. The SE may ONLY modify production code and test code. 3. Run `task test-fast` to confirm the test passes (GREEN). diff --git a/.opencode/skills/polish-code/SKILL.md b/.opencode/skills/polish-code/SKILL.md index 9334466..2054698 100644 --- a/.opencode/skills/polish-code/SKILL.md +++ b/.opencode/skills/polish-code/SKILL.md @@ -8,7 +8,7 @@ description: "Apply full project conventions — naming, docstrings, formatting, Available knowledge: [[software-craft/tdd#key-takeaways]], [[writing/ai-language-markers#key-takeaways]]. `in` artifacts: read all before starting work. 1. Run `task conventions` to see all convention violations (naming, docstrings, formatting, import sorting, etc.). -2. Fix each violation manually. Do NOT use `--fix` (it can break code). +2. Fix **all** violations codebase-wide, not just those introduced in the current feature. Resolve each at its source; do not suppress with `noqa`. Do NOT use `--fix` (it can break code). 3. Run `ruff format .` to apply consistent formatting. 4. Add Google-style docstrings to all public classes and methods where missing. 5. Add type annotations to all public signatures where missing. diff --git a/.opencode/skills/refactor/SKILL.md b/.opencode/skills/refactor/SKILL.md index a5c3b7b..74a434d 100644 --- a/.opencode/skills/refactor/SKILL.md +++ b/.opencode/skills/refactor/SKILL.md @@ -5,13 +5,13 @@ description: "Improve code structure while keeping all tests passing, then cycle # Refactor -Available knowledge: [[software-craft/tdd]], [[software-craft/refactoring]], [[software-craft/object-calisthenics]], [[software-craft/smell-catalogue]], [[software-craft/refactoring-techniques]]. `in` artifacts: read all before starting work. +Available knowledge: [[software-craft/tdd]], [[software-craft/refactoring]], [[software-craft/object-calisthenics]], [[software-craft/smell-catalogue]], [[software-craft/refactoring-techniques]], [[software-craft/solid]], [[software-craft/design-patterns]]. `in` artifacts: read all before starting work. 1. Review the code for improvement opportunities while keeping all tests passing per [[software-craft/tdd#concepts]]. 2. Refactor only if there is a test that would break if the refactoring is wrong per [[software-craft/tdd#key-takeaways]]. 3. Apply small steps: one refactoring at a time, tests green after each step, no new functionality per [[software-craft/refactoring#key-takeaways]]. 4. Apply design-only transformations per [[software-craft/tdd#concepts]]: YAGNI > KISS > DRY > ObjCal > Smells > SOLID > patterns. Do not apply convention compliance (docstrings, type hints, import ordering, format changes). Those belong in the Conventions Phase. -5. Detect improvement opportunities per the design principle priority in [[software-craft/tdd#content]], loading ObjCal per [[software-craft/object-calisthenics#key-takeaways]], smells per [[software-craft/smell-catalogue#key-takeaways]], and SOLID per [[software-craft/solid#key-takeaways]]. Apply the appropriate refactoring technique per [[software-craft/refactoring-techniques#concepts]]. +5. Detect improvement opportunities per the full design principle priority in [[software-craft/tdd#content]]: YAGNI per [[software-craft/tdd#concepts]], KISS per [[software-craft/tdd#concepts]], DRY per [[software-craft/tdd#concepts]], ObjCal per [[software-craft/object-calisthenics#key-takeaways]], smells per [[software-craft/smell-catalogue#key-takeaways]], SOLID per [[software-craft/solid#key-takeaways]], patterns per [[software-craft/design-patterns#key-takeaways]]. Apply the appropriate refactoring technique per [[software-craft/refactoring-techniques#concepts]]. 6. IF no improvement is needed → skip refactoring and proceed to the next test. 7. IF a spec gap or inconsistency is discovered during refactoring → do NOT modify specification documents (domain_spec.md, glossary.md, product_definition.md, ADRs, feature files). Flag it in output notes. The SE may ONLY modify production code and test code. 8. Commit refactor changes separately from feature changes per [[software-craft/git-conventions#concepts]]. diff --git a/.opencode/skills/review-gate/SKILL.md b/.opencode/skills/review-gate/SKILL.md index 304d1ec..6052634 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/test-stubs]], [[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]], [[software-craft/object-calisthenics]], [[software-craft/solid]], [[software-craft/tdd]], [[software-craft/design-patterns]], [[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. @@ -15,12 +15,20 @@ Available knowledge: [[software-craft/code-review]], [[software-craft/test-desig 2. Verify implementation aligns with architectural decisions per [[software-craft/code-review#concepts]]: ADR compliance, quality attributes met. 3. Verify all `# Constraints:` in the .feature file are met in the implementation. For technology constraints, read domain_spec.md `### Technology Requirements` table and execute the Verification instruction for each row (grep imports, check file existence, inspect config). Zero evidence → FAIL. For quality attribute constraints, verify thresholds are enforced. 4. Verify implementation aligns with feature specification: all Examples have corresponding test implementations, behavior matches Gherkin steps. -5. Verify design principles adversarially per the priority order in [[software-craft/tdd#content]], loading the full documents for detection: ObjCal per [[software-craft/object-calisthenics]], smells per [[software-craft/smell-catalogue]], and SOLID per [[software-craft/solid]]. Use `#key-takeaways` only when recalling principles, not when detecting violations. +5. Verify each design principle adversarially per the priority order in [[software-craft/tdd#content]]. Load the full document for detection at each sub-step. Fail-fast at first violation: + + a) YAGNI per [[software-craft/tdd#concepts]]: no premature abstractions, no speculative generalization, no future-proofing beyond what failing tests require. + b) KISS per [[software-craft/tdd#concepts]]: simplest solution chosen; no over-engineered alternatives where a direct approach suffices. + c) DRY per [[software-craft/tdd#concepts]]: no duplicated logic or duplicated knowledge. Duplication is acceptable only when DRY would create wrong coupling. + d) ObjCal per [[software-craft/object-calisthenics]]: verify all 9 rules with detection heuristics. + e) Smells per [[software-craft/smell-catalogue]]: detect each smell with file:line evidence. + f) SOLID per [[software-craft/solid]]: verify each principle with detection heuristics. + g) Patterns per [[software-craft/design-patterns]]: every pattern must be justified by a requirement, not added speculatively. 6. **FAIL-FAST**: If any design violations found → exit `fail` with specific citations (file:line). Do NOT proceed to structure review. ## Tier 2: Structure Review -7. Run `beehave check` per [[software-craft/test-stubs#concepts]]. +7. Run `beehave status --json` per [[software-craft/test-stubs#concepts]]. IF feature stage is `ok` with no violations → structural traceability is clean. IF not `ok` → run `beehave check` per [[software-craft/test-stubs#concepts]] and verify all violations resolved. 8. Verify test quality per [[software-craft/test-design#concepts]]: tests follow AAA pattern, clear assertions, behavior-focused not implementation-coupled. 9. Run `task test` and verify all tests pass with coverage. 10. Run `ruff check .` and verify no functional lint violations (the default ruff config only includes bug-catching rules). diff --git a/.opencode/skills/select-feature/SKILL.md b/.opencode/skills/select-feature/SKILL.md index 1b2d2f0..3ba870c 100644 --- a/.opencode/skills/select-feature/SKILL.md +++ b/.opencode/skills/select-feature/SKILL.md @@ -25,4 +25,4 @@ Available knowledge: [[requirements/wsjf#key-takeaways]], [[software-craft/test- - Estimate Value (1-5, mapped to Kano categories) and Effort (1-5, mapped to complexity). - Compute WSJF = Value / Effort. - Select the highest WSJF score; ties broken by Value. -8. Set the `feature_id` session param to the selected feature's filename stem (without `.feature` extension). +8. Set the `feature_title` session param to the selected feature's filename stem (without `.feature` extension). diff --git a/.opencode/skills/setup-apply/SKILL.md b/.opencode/skills/setup-apply/SKILL.md index b69c7da..823d75d 100644 --- a/.opencode/skills/setup-apply/SKILL.md +++ b/.opencode/skills/setup-apply/SKILL.md @@ -5,7 +5,7 @@ description: "Apply text substitutions, rename package directory, and write temp # Setup Apply -`in` artifacts: read all before starting work. +Available knowledge: [[software-craft/versioning]]. `in` artifacts: read all before starting work. 1. Rename the package directory: `mv app {package_name}` 2. Apply every substitution from `template-config.yaml` substitutions section in order: diff --git a/.opencode/skills/simulate-spec/SKILL.md b/.opencode/skills/simulate-spec/SKILL.md index 3a77e3f..6cc5f1d 100644 --- a/.opencode/skills/simulate-spec/SKILL.md +++ b/.opencode/skills/simulate-spec/SKILL.md @@ -17,7 +17,7 @@ Available knowledge: [[requirements/spec-simulation]], [[requirements/gherkin#ke - Does the spec cover this walkthrough? If not, that is a pain point. 5. Create I/O evidence in `.cache/sim//` per [[requirements/spec-simulation#concepts]]: `walkthrough__in.json` and `walkthrough__out.json` pairs. These files prove the simulation was walked and provide concrete examples for later test writing. 6. Classify and record pain points per [[requirements/spec-simulation#concepts]]. -7. Write each discovered rule as a Rule block in the appropriate .feature file. Use the template at `.templates/docs/features/.feature.template` to create the file for each bounded context. The Rule block format: `Rule: <2-6 word title>` followed by a behavioral description paragraph. Each rule must cite the walkthrough that discovered it. +7. Write each discovered rule as a Rule block in the appropriate .feature file. Use the template at `.templates/docs/features/.feature.template` to create the file for each bounded context. The Rule block format: `Rule: <2-6 word title>` followed by a behavioral description paragraph. Each rule must cite the walkthrough that discovered it. 7a. Verify all titles meet constraints per [[requirements/gherkin#key-takeaways]]: every Feature title is 2–6 words and unique across all .feature files; every Rule title is 2–6 words and unique within its .feature file. Count words by splitting on whitespace. If a title fails, rephrase and re-check. 8. For each bounded context, read the `### Technology Requirements` table in domain_spec.md. Write each technology requirement as a `# Constraints:` entry in the context's .feature file. Use the Verification column's instruction as the constraint text. Technology constraints carry implementation mandates forward from the domain spec to the artifacts the SE reads. 9. Record walkthrough→rule provenance in the simulation results file: each walkthrough's `Discovered Rule` column references the Rule title written to the .feature file. diff --git a/.opencode/skills/verify-traceability/SKILL.md b/.opencode/skills/verify-traceability/SKILL.md index 776e99e..32ef908 100644 --- a/.opencode/skills/verify-traceability/SKILL.md +++ b/.opencode/skills/verify-traceability/SKILL.md @@ -7,5 +7,5 @@ description: "Verify example-to-test traceability via beehave check and semantic 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]]. Optionally use `beehave status --json` for a summary view of the feature's development stage. +1. Run `beehave status --json` per [[software-craft/test-stubs#concepts]]. IF the feature stage is `ok` with no violations → structural traceability is verified; skip to step 2. IF not `ok` → run `beehave check` per [[software-craft/test-stubs#concepts]] to get the detailed violation list and verify all are resolved. 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/.opencode/skills/write-bdd-features/SKILL.md b/.opencode/skills/write-bdd-features/SKILL.md index c7a4740..2a4b762 100644 --- a/.opencode/skills/write-bdd-features/SKILL.md +++ b/.opencode/skills/write-bdd-features/SKILL.md @@ -29,4 +29,4 @@ Available knowledge: [[requirements/gherkin]], [[requirements/moscow]], [[requir a) Every quoted string or bare number must identify an entity, boundary, configuration, or error case — not serve as display text. b) Every column in a Scenario Outline Examples table must be referenced in at least one step. If the expected outcome is a deterministic function of inputs, express the relationship in the `Then` step rather than adding a computed output column. Remove or reword any value that fails this check before advancing. -10. Run `beehave check ` to verify structural traceability catches issues at write time. Fix any errors before committing. \ No newline at end of file +10. Run `beehave check ` to verify structural traceability catches issues at write time. Fix any errors before committing. \ No newline at end of file diff --git a/.opencode/skills/write-test/SKILL.md b/.opencode/skills/write-test/SKILL.md index 908c39f..05c116a 100644 --- a/.opencode/skills/write-test/SKILL.md +++ b/.opencode/skills/write-test/SKILL.md @@ -10,6 +10,6 @@ Available knowledge: [[software-craft/tdd]], [[software-craft/test-design]], [[s 1. Pick the next test function with an `...` (Ellipsis) body from the auto-generated test stubs: prefer tests within the same Rule file before moving to the next Rule, and order by fewest dependencies first per [[software-craft/tdd#concepts]]. pytest-beehave creates stubs with `test_` naming and `...` bodies (auto-skipped during collection). IF the Example belongs to a structural (invariant) Rule → also generate a Hypothesis property test in `tests/unit/` per [[software-craft/test-design#concepts]], using the counterexamples surfaced by the behavior pre-mortem per [[requirements/pre-mortem#concepts]]. 2. **External fixture gate**: IF the Example/Scenario Outline references an external adapter or API (check domain spec External Contracts section), verify the real fixture exists in `tests/fixtures//` per [[software-craft/external-fixtures#key-takeaways]]. IF the fixture is missing → flag as a blocker. Do NOT write the test against imagined data. Request fixture capture before proceeding. 3. Write a failing test that specifies the expected behavior per [[software-craft/tdd#key-takeaways]]. Replace the `...` body with the test implementation. The test function name (derived from the Example title) is immutable — it is the traceability link maintained by pytest-beehave. For Scenario Outline stubs with `@given`/`@example` decorators, use the placeholder parameters in the test body: - - All placeholders and literals from the spec steps must appear in the test body per Spec Value Fidelity ([[software-craft/test-design#concepts]]) — `beehave check` verifies their presence. Use each value in a way that reflects its domain purpose: identifiers identify, boundaries bound, configurations configure. Never add noise code to satisfy traceability. + - All placeholders and literals from the spec steps must appear in the test body per Spec Value Fidelity ([[software-craft/test-design#concepts]]) — `beehave check` verifies their presence. Before writing: identify the single observable behavior this Example specifies. The test body must verify exactly that behavior through the right entry point — no assertions, setup, or teardown unrelated to the Example's intent. Use each value to reflect its domain purpose: identifiers identify, boundaries bound, configurations configure. Noise that satisfies traceability without domain meaning — assigning to `_`, literals in assert messages, helper functions whose sole purpose is consuming a value — violates Spec Value Fidelity per [[software-craft/test-design#concepts]]. If a spec value does not fit naturally, flag the mismatch in output notes; do not work around it. 4. IF a spec gap or inconsistency is discovered → do NOT modify specification documents (domain_spec.md, glossary.md, product_definition.md, ADRs, feature files). Flag it in output notes. The SE may ONLY modify production code and test code. 5. Run `task test-fast` to confirm the test fails for the right reason (RED) per [[software-craft/tdd#key-takeaways]]. diff --git a/.templates/docs/features/.feature.template b/.templates/docs/features/.feature.template similarity index 100% rename from .templates/docs/features/.feature.template rename to .templates/docs/features/.feature.template diff --git a/.templates/tests/features/_test.py.template b/.templates/tests/features/_test.py.template new file mode 100644 index 0000000..86bb01d --- /dev/null +++ b/.templates/tests/features/_test.py.template @@ -0,0 +1,12 @@ +"""BDD test stubs for — . + +Auto-generated by `beehave generate `. Each stub has an `...` (Ellipsis) body +and is auto-skipped by pytest-beehave during collection. +The SE replaces `...` with the test implementation during the RED phase. +""" + +from pytest_beehave import given, then, when + + +def test_() -> None: + ... diff --git a/AGENTS.md b/AGENTS.md index b36fc40..88471db 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -7,7 +7,7 @@ Post-mortem analysis shows these practices prevent most project failures. Violat 3. **Never collapse progressive gates.** Multi-step gates (review: design → structure) are separate for a reason. Each one can fail independently and send work back. Conventions (naming, docstrings, formatting) are enforced in a separate polish state after feature acceptance. 4. **Never decompose a feature without stakeholder approval.** If a feature is too large for INVEST, propose the split to the stakeholder with rationale. They decide what's core vs. deferred. 5. **Verify inputs exist before entering a state.** Every state's `in` artifacts must be readable on disk. If they're missing, stop and reconstruct them. Don't proceed with assumed knowledge. -6. **A feature is not done until every interview requirement is traced.** Every stakeholder Q&A must map to either a passing @id test or an explicit stakeholder deferral. Untraced requirements = incomplete delivery. +6. **A feature is not done until every interview requirement is traced.** Every stakeholder Q&A must map to either a passing traceable test or an explicit stakeholder deferral. Untraced requirements = incomplete delivery. 7. **Respect git branch discipline.** Every state declares `git: dev`, `git: feature`, or `git: main` in its attrs. **Verify the current branch matches `attrs.git` before starting any work.** If the branch is wrong, checkout or create the correct branch before proceeding. Never switch branches mid-state. Before exiting a project-phase flow (discovery, architecture, branding, setup), set `committed-to-dev-locally: ==verified` evidence. Changes must be committed to dev before advancing. 8. **Every feature branch must be merged back to dev.** A feature is not delivered until its commits are squash-merged into local dev and `task test-fast` passes on dev. The develop-flow exits to deliver-flow which handles the merge, but the orchestrator must never leave a feature branch dangling — if the session ends mid-feature, resume and complete the merge before starting new work. @@ -21,10 +21,10 @@ Post-mortem analysis shows these practices prevent most project failures. Violat When creating a document, use the template in `.templates/` that matches the artifact type. Strip the `.templates/` prefix and `.template` suffix to determine the destination path. For example: - `.templates/docs/adr/ADR_YYYYMMDD_.md.template` → `docs/adr/ADR_20260430_my_decision.md` -- `.templates/docs/features/.feature.template` → `docs/features/my_feature.feature` +- `.templates/docs/features/.feature.template` → `docs/features/my_feature.feature` - `.templates/.cache/interview-notes/IN_YYYYMMDD_.md.template` → `.cache/interview-notes/IN_20260430_session_management.md` - `.templates/.cache/sim/simulation_results_YYYYMMDDTHHMMSS.md.template` → `.cache/sim/simulation_results_20260517T143000.md` -- `.templates/.cache/acceptance/.md.template` → `.cache/acceptance/domain_value_objects.md` +- `.templates/.cache/acceptance/.md.template` → `.cache/acceptance/domain_value_objects.md` If no template exists for an artifact type, create the document without one. @@ -76,7 +76,7 @@ Artifact names in `in` and `out` lists use these conventions: | Pattern | Meaning | Example | |---------|---------|---------| | `filename.md` | A specific document | `domain_spec.md`, `product_definition.md` | -| `dir/.ext` | A specific instance identified by parameter | `features/.feature`, `.cache/interview-notes/.md`, `adr/.md` | +| `dir/.ext` | A specific instance identified by parameter | `features/.feature`, `.cache/interview-notes/.md`, `adr/.md` | | `dir/*.ext` | Multiple documents of that type available in `in` | `.cache/interview-notes/*.md`, `adr/*.md` | | `conceptual_name` | A runtime artifact that passes between states within a flow | `typed-source-stubs`, `test-implementations` | @@ -86,9 +86,9 @@ Placeholders in template filenames and flow artifact paths use the `` p **Wildcards (`*`)** in `in` indicate that multiple documents of that type are available. List the directory contents first, then read selectively based on the task. When a state creates a single instance, use a `` name instead. -**Runtime artifacts** (not backed by files) use descriptive names that make their purpose clear: `typed-source-stubs` (source files with type signatures only), `test-skeletons` (test files with structure only), `test-implementations` (tests with bodies), `source-implementations` (production code with behavior), `refactored-source` (code after refactoring pass), `feature-commits` (git commits for one feature), `merged-commits` (commits merged to local main), `root-cause-analysis` (analysis findings), `polished-source` (code after convention application). +**Runtime artifacts** (not backed by files) use descriptive names that make their purpose clear: `typed-source-stubs` (source files with type signatures only), `test-skeletons` (test files with structure only), `test-implementations` (tests with bodies), `source-implementations` (production code with behavior), `refactored-source` (code after refactoring pass), `feature-commits` (git commits for one feature), `merged-commits` (commits merged to local dev), `root-cause-analysis` (analysis findings), `polished-source` (code after convention application). -**Cache artifacts** are persisted to `.cache/` for cross-session durability. They are not spec documents but process evidence that survives session boundaries: `.cache/acceptance/.md` (PO acceptance record with traceability matrix), `.cache/interview-notes/.md` (raw stakeholder input, archival after discovery), `.cache/sim/simulation_results_.md` (simulation evidence per iteration). +**Cache artifacts** are persisted to `.cache/` for cross-session durability. They are not spec documents but process evidence that survives session boundaries: `.cache/acceptance/.md` (PO acceptance record with traceability matrix), `.cache/interview-notes/.md` (raw stakeholder input, archival after discovery), `.cache/sim/simulation_results_.md` (simulation evidence per iteration). **Environment artifacts** are produced by tooling rather than flow states: `coverage-reports` (test coverage output), `test-output` (test runner output), `linter-output` (linter output). These exist on disk after running the relevant tool and are referenced in `in` but not in any state's `out`. @@ -96,7 +96,7 @@ Placeholders in template filenames and flow artifact paths use the `` p All commands output **JSON by default**. Use `--text` for human-readable output. All commands require the virtual environment: `source .venv/bin/activate`. See [[workflow/flowr-operations]] for full command reference, output formats, and workflow pattern. -Commands accept short flow names (e.g., `planning-flow`) or full file paths. Use `--session ` to resolve flow/state from a session instead of specifying them explicitly. +Commands accept short flow names (e.g., `define-flow`) or full file paths. Use `--session ` to resolve flow/state from a session instead of specifying them explicitly. | Command | Purpose | |---------|---------| @@ -144,7 +144,7 @@ Every state transition must go through flowr. Do not skip steps or guess transit 1. **State entry:** Run `python -m flowr check --session` to see current state, owner, skills, and available transitions (JSON output: parse `attrs.owner`, `attrs.skills`, `attrs.in`, `attrs.out`, `transitions`). Verify all `in` artifacts exist on disk. If any are missing, stop and flag rather than proceeding with assumed knowledge. Announce the state in one line, e.g. `→ specify-feature`. No preamble, no recap of how you got here. 2. **Dispatch to owner agent:** The state's `owner` field names the responsible agent. Call that agent as a subagent with the state's `skills` loaded, passing the state attrs as context. Owner mapping: `PO` → product-owner, `DE` → domain-expert, `SE` → software-engineer, `SA` → system-architect, `R` → reviewer, `Design Agent` → design-agent, `Setup Agent` → setup-agent. -3. **Do the work:** Load and execute the skill(s) listed in the state's `skills` field. Read all `in` artifacts before starting work — they are mandatory context. Write only to `out` artifacts. Commit changes to the branch indicated by the state's `git` attribute (`main` or `feature`). Never switch branches mid-state. +3. **Do the work:** Load and execute the skill(s) listed in the state's `skills` field. Read all `in` artifacts before starting work — they are mandatory context. Write only to `out` artifacts. Commit changes to the branch indicated by the state's `git` attribute (`dev` or `feature`). Never switch branches mid-state. 4. **State exit:** The anchor item in the todo handles this (see [[workflow/todo-anchor-protocol#key-takeaways]]). ### Convention Boundary @@ -202,7 +202,7 @@ When post-mortem-flow exits `needs-architecture`, follow the same procedure: re- ### Branch Discipline States declare their git context in `attrs.git`: -- `git: main`: all changes are committed to the local main branch +- `git: dev`: all changes are committed to the local dev branch - `git: feature`: all changes are committed to the current feature branch Before exiting a project-phase flow (define, branding, setup), the exit transition requires `committed-to-dev-locally: ==verified` evidence. This guarantees project artifacts are persisted before advancing to the next phase. diff --git a/CHANGELOG.md b/CHANGELOG.md index c8c3408..39e60ca 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -137,7 +137,7 @@ All notable changes to this template will be documented in this file. - **Committed-to-main guards**: Project-phase exit transitions (discovery, architecture, planning, branding, setup) now require `committed_to_main_locally: ==verified` evidence before advancing. Ensures artifacts are persisted before moving to the next phase. - **flowr 0.4.0 adoption**: Upgraded dependency from `>=0.3` to `>=0.4`. Added `[tool.flowr]` config section to pyproject.toml (flows_dir, sessions_dir, default_flow, default_session). - **Session management**: `.flowr/sessions/` directory for persisting workflow progress. AGENTS.md updated with session init, `--session` flag usage, and session-based workflow pattern. -- **Flow params**: Feature-scoped flows (planning, development, delivery, tdd-cycle, review-gate, feature-development) now declare `params: [feature_name]` for session parameter tracking. +- **Flow params**: Feature-scoped flows (planning, development, delivery, tdd-cycle, review-gate, feature-development) now declare `params: [feature_title]` for session parameter tracking. - **Flowr commands**: AGENTS.md and knowledge files updated with session commands (`init`, `show`, `set-state`, `list`), `--session` flag on check/next/transition, `config` command, short flow name resolution, and `--evidence-json` flag. - **flowr-spec.md knowledge**: Session model (flow, state, name, stack, params), configuration resolution, MUST/SHOULD severity levels on validation rules, atomic session writes principle. - **flowr-operations.md knowledge**: Session commands, session-based workflow pattern, configuration section, evidence syntax with condition operators. diff --git a/README.md b/README.md index 86ba88b..bbdd0d5 100644 --- a/README.md +++ b/README.md @@ -31,7 +31,7 @@ Flow definitions in YAML declare what happens at each state: who owns it, what t ### Developers moving from vibe coding to agentic engineering -You have shipped code with AI assistants and hit the wall: the agent writes code, you review it, the spec drifts. Vibe coding works for prototypes. It breaks at scale. temple8 replaces "prompt and pray" with spec-driven development: BDD scenarios from interviews, `@id` traceability from scenario to test function, red-green-refactor cycles enforced by default, three-tier review that catches what linters miss. +You have shipped code with AI assistants and hit the wall: the agent writes code, you review it, the spec drifts. Vibe coding works for prototypes. It breaks at scale. temple8 replaces "prompt and pray" with spec-driven development: BDD scenarios from interviews, title-based traceability from Example to test function, red-green-refactor cycles enforced by default, three-tier review that catches what linters miss. ### Teams wanting structured agent orchestration without lock-in diff --git a/docs/audit/document-landscape-audit.md b/docs/audit/document-landscape-audit.md index a951650..085df3e 100644 --- a/docs/audit/document-landscape-audit.md +++ b/docs/audit/document-landscape-audit.md @@ -150,7 +150,7 @@ How many states READ each document. Higher consumption = higher system value. | `Rules (Business)` | **COULD** | Coarse rules from discovery (feature-discovery state). **Superseded by `rules` after feature-breakdown runs.** The refined `rules` section contains the same information in INVEST-validated form. | | `Constraints` | **MUST** | Non-functional requirements specific to this feature. References product_definition quality_attributes. | | `Rules` | **MUST** | INVEST-validated rule blocks with user stories. The actual specification. | -| `Examples` | **MUST** | Given/When/Then BDD scenarios with @id tags. These ARE the test specification. The most critical section for code generation. | +| `Examples` | **MUST** | Given/When/Then BDD scenarios. These ARE the test specification. The most critical section for code generation. | | `Questions` | **SHOULD** | Open/resolved Q&A. Useful for audit but not needed for rebuild. | | `Changes` | **COULD** | Audit trail. | @@ -339,7 +339,7 @@ Each layer consumes the one below it. No document can be eliminated without losi | 2 | `glossary.md` | Consistent naming across all generated code | All entries | | 3 | `technical_design.md` | Stack choice, module layout, API contracts, event contracts, port interfaces, dependencies, config keys | All 10 sections (C4 Diagrams optional) | | 4 | `product_definition.md` | Scope boundaries, users, quality attributes, definition of done, deployment checklist | 7 of 8+ sections (Why optional, Branch Strategy not needed) | -| 5 | `features/*.feature` | Per-feature: rules (user stories) and examples (BDD Given/When/Then with @id tags) | title, description, Rules, Examples, Constraints (5 of 6+ sections) | +| 5 | `features/*.feature` | Per-feature: rules (user stories) and examples (BDD Given/When/Then) | title, description, Rules, Examples, Constraints (5 of 6+ sections) | | 6 | `system.md` | Current-state architecture, key decisions, active constraints | Summary, Delivery, Context, Container, Module Structure, Domain Model Documentation, Active Constraints, Key Decisions (8 of 9+ sections) | ### What rebuild would miss without SHOULD documents diff --git a/pyproject.toml b/pyproject.toml index e2e733f..8ed8776 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "temple8" -version = "9.1.0" +version = "9.2.0" description = "Spec-driven agent orchestration template with YAML flow definitions, multi-agent dispatch, and BDD traceability" readme = "README.md" requires-python = ">=3.14" @@ -31,7 +31,7 @@ dev = [ "hypothesis>=6.148.4", "pyright>=1.1.407", "ghp-import>=2.1.0", - "flowr>=1.0.0", + "flowr>=1.1.0", "beehave>=1.0.0", "pytest-beehave>=1.0.0", "safety>=3.7.0", diff --git a/uv.lock b/uv.lock index e3e0a4e..70cc59a 100644 --- a/uv.lock +++ b/uv.lock @@ -276,14 +276,14 @@ wheels = [ [[package]] name = "flowr" -version = "1.0.0" +version = "1.1.0" source = { registry = "https://pypi.org/simple" } dependencies = [ { name = "pyyaml" }, ] -sdist = { url = "https://files.pythonhosted.org/packages/0c/73/22cf442d7dee23efb6b79a30d204c8b8dcef883a37293f495c506d129c8f/flowr-1.0.0.tar.gz", hash = "sha256:87e4672b41826d1f7e7f1c0c587427f1bb6b25cf462dc5889a0fb919e599f833", size = 27152, upload-time = "2026-05-06T15:45:05.704Z" } +sdist = { url = "https://files.pythonhosted.org/packages/6e/ae/92f43a73ca36b6b019eeefcc7f0238327c0bf4c9ad4c60fe327d5bbe0b6b/flowr-1.1.0.tar.gz", hash = "sha256:20f26b0544fb2302a17dd3c06d82cd7f16e4116da1d403ba01190cbaf948cad7", size = 37558, upload-time = "2026-05-19T20:41:00.569Z" } wheels = [ - { url = "https://files.pythonhosted.org/packages/6b/ea/620ffffa51516c809309d8ccc79dddef2b050f851f3a297214b901a9ffb4/flowr-1.0.0-py3-none-any.whl", hash = "sha256:4b1aac01198ee4a14cca6b55299481db955bc111f48a57c228a7f8649d920444", size = 27168, upload-time = "2026-05-06T15:45:04.088Z" }, + { url = "https://files.pythonhosted.org/packages/69/5e/610aec9a6e6e7c39e75c647cb48ab517d4a4c1af0385ddfea0a32744db4f/flowr-1.1.0-py3-none-any.whl", hash = "sha256:15100762733e7f915b4877425ab28f1e6f512124e83e4404a5c6731f947cd728", size = 39778, upload-time = "2026-05-19T20:40:59.239Z" }, ] [[package]] @@ -955,7 +955,7 @@ wheels = [ [[package]] name = "temple8" -version = "9.1.0" +version = "9.2.0" source = { virtual = "." } [package.optional-dependencies] @@ -984,7 +984,7 @@ dev = [ [package.metadata] requires-dist = [ { name = "beehave", marker = "extra == 'dev'", specifier = ">=1.0.0" }, - { name = "flowr", marker = "extra == 'dev'", specifier = ">=1.0.0" }, + { name = "flowr", marker = "extra == 'dev'", specifier = ">=1.1.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" },