fix: consistency audit — feature_name convention, git:dev references, stale exits, agent ownership

.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_id>.feature":
+        - "features/<feature_title>.feature":
             - feature_header
             - constraints
             - rules

.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/<feature_id>.md"
-        - features/<feature_id>.feature
+        - ".cache/acceptance/<feature_title>.md"
+        - features/<feature_title>.feature
       out:
         - merged-commits
     next:
@@ -47,7 +47,7 @@ states:
         - create-pr
       in:
         - merged-commits
-        - features/<feature_id>.feature
+        - features/<feature_title>.feature
       out: []
     conditions:
       merged:

.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_id>.feature"
+        - "features/<feature_title>.feature"
       out: []
     next:
       selected: feature-examples
@@ -32,12 +31,12 @@ states:
       skills:
         - write-bdd-features
       in:
-        - features/<feature_id>.feature
+        - features/<feature_title>.feature
         - product_definition.md
         - domain_spec.md
         - glossary.md
       out:
-        - features/<feature_id>.feature:
+        - features/<feature_title>.feature:
             - examples
     conditions:
       examples-complete:
@@ -55,7 +54,7 @@ states:
       skills:
         - review-spec
       in:
-        - features/<feature_id>.feature
+        - features/<feature_title>.feature
         - product_definition.md
         - domain_spec.md
         - glossary.md
@@ -87,13 +86,13 @@ states:
         - accept-feature
         - verify-traceability
       in:
-        - features/<feature_id>.feature
+        - features/<feature_title>.feature
         - product_definition.md
         - domain_spec.md
         - glossary.md
         - ".cache/interview-notes/*.md"
       out:
-        - ".cache/acceptance/<feature_id>.md"
+        - ".cache/acceptance/<feature_title>.md"
     conditions:
       feature-accepted:
         acceptance-verified: ==verified
@@ -113,7 +112,7 @@ states:
       in:
         - source-implementations
         - test-implementations
-        - features/<feature_id>.feature
+        - features/<feature_title>.feature
       out:
         - polished-source
     next:
@@ -129,7 +128,7 @@ states:
       in:
         - polished-source
         - test-implementations
-        - features/<feature_id>.feature
+        - features/<feature_title>.feature
       out:
         - feature-commits
     conditions:

.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_id>.feature
+        - features/<feature_title>.feature
         - domain_spec.md
         - glossary.md
         - product_definition.md
@@ -30,7 +30,7 @@ states:
       skills:
         - create-py-stubs
       in:
-        - features/<feature_id>.feature
+        - features/<feature_title>.feature
         - domain_spec.md
         - glossary.md
         - product_definition.md
@@ -86,7 +86,7 @@ states:
       in:
         - test-implementations
         - source-implementations
-        - features/<feature_id>.feature
+        - features/<feature_title>.feature
         - domain_spec.md
         - "adr/*.md"  # optional
       out: []
@@ -104,7 +104,7 @@ states:
       in:
         - source-implementations
         - test-implementations
-        - features/<feature_id>.feature
+        - features/<feature_title>.feature
       out:
         - feature-commits
     conditions:

.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_id>.feature
+        - features/<feature_title>.feature
         - domain_spec.md
         - glossary.md
       out:
@@ -33,7 +33,7 @@ states:
       in:
         - test-implementations
         - typed-source-stubs
-        - features/<feature_id>.feature
+        - features/<feature_title>.feature
         - domain_spec.md
         - glossary.md
       out:
@@ -51,7 +51,7 @@ states:
       in:
         - source-implementations
         - test-implementations
-        - features/<feature_id>.feature
+        - features/<feature_title>.feature
         - domain_spec.md
         - glossary.md
       out:

.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.
+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.

.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)

.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/<stem>`) 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 <feature_id>` 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 <feature_title>` to create test stubs per [[software-craft/test-stubs#key-takeaways]], (5) run `beehave check` to verify all Examples have corresponding test stubs.
 
 ## Related
 

.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 <feature_id>` 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_<example_title_slug>`.
+- Test stubs are auto-generated by `beehave generate <feature_title>` 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_<example_title_slug>`.
 - `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 <feature_id>` 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 <feature_title>` 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.
 

.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 <feature_id>` to generate test stubs from the feature file per [[software-craft/test-stubs#concepts]]:
+3. Run `beehave generate <feature_title>` 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

.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).

.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.

.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]].