docs: integrate BDD into use-case and feature lifecycle

[dapi]

Problem

Memory Bank distinguishes project-level UC-*, feature acceptance scenarios SC-* / NEG-*, checks CHK-*, and derived feature-local FUC-*, but it does not define Behaviour-Driven Development as an explicit Discovery → Formulation → Automation practice.

Without a governed contract, projects may duplicate requirements in Gherkin, treat BDD as an E2E testing framework, or create a parallel canonical scenario hierarchy.

Outcome

Integrate BDD as a cross-cutting behavior-specification practice without creating a new delivery route or a second owner for requirements and acceptance.

Target traceability:

UC → BR/REQ → SC/NEG → CHK → automated test → EVID

Scope

• Add a canonical behavior-specification practice covering Discovery, Formulation, Automation, scenario quality, ownership, and change propagation.
• Extend Feature Flow gates so concrete examples are discovered before Problem Ready, formulated as observable SC-* / NEG-*, and mapped to checks and automation by Plan Ready / Done.
• Extend Use Case Flow with downstream behavior coverage and impact-analysis rules while keeping UC-* the owner of the stable project-level scenario.
• Update the feature brief and use-case templates with BDD-friendly structure and traceability.
• Replace or reshape the optional feature-local use-case companion as a derived behavior-example view without new canonical requirements or checks.
• Update testing policy to clarify that BDD does not require Gherkin, Cucumber, UI automation, or E2E-only tests.
• Update priming manifests, template indexes, artifact catalog, and README navigation.
• Add the original Dan North BDD article to README as the methodology source.

Non-goals

• Do not add a memory-bank/bdd/ top-level catalog.
• Do not add a new Task Routing branch.
• Do not make Gherkin or Cucumber mandatory.
• Do not introduce canonical BDD-* identifiers.
• Do not move feature acceptance ownership out of brief.md.

Acceptance criteria

• BDD has one canonical practice document and is reachable from the relevant indexes.
• Discovery outputs route to existing owners: rules to domain/REQ-*, examples to SC-* / NEG-*, questions to DEC-*, and excluded work to NS-* or another delivery unit.
• Problem Ready checks scenario observability, concrete context/event/outcome, and requirement coverage.
• Plan Ready and Done require traceability from scenarios to checks, test surfaces, and evidence.
• UC-* remains canonical for goal, actor, trigger, preconditions, flow, alternatives, rules, and postconditions.
• Templates clearly separate stable use cases, acceptance examples, checks, and executable test code.
• README links to Dan Norths original Introducing BDD article as the methodology source.
• Template validation, lint, doctor, and whitespace checks pass.