feat: add behavioral test requirement to TDD workflow and acceptance criteria (merge worktree-20260323-193735)

Author: JoeOakhartNava

plugins/dso/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "dso",
-  "version": "0.25.20",
+  "version": "0.25.21",
   "description": "Workflow infrastructure plugin for Claude Code projects",
   "commands": "./commands/",
   "skills": "./skills/",

plugins/dso/docs/ACCEPTANCE-CRITERIA-LIBRARY.md

@@ -119,6 +119,8 @@ Use when a task removes, moves, or replaces a command, skill, script, or other w
   Verify: grep -q 'def {test_name}' {test_path}
 - [ ] Running the test returns non-zero exit pre-implementation
   Verify: python -m pytest {test_path}::{test_name} 2>&1; test $? -ne 0
+- [ ] Test is behavioral: executes the code under test (calls a function, runs a script, or exercises a code path with inputs and asserts on outputs/side effects) — not a grep/sed scan of the source file for implementation strings. Structural tests (negative constraints, metadata validation, syntax checks) are exempt.
+  Verify: manual review — test approach in task description describes what is executed and what output is asserted
 
 ## Category: Test-Exempt Task
 

plugins/dso/skills/implementation-plan/SKILL.md

@@ -282,6 +282,30 @@ A RED test task:
 - Must fail (RED) before the implementation task runs
 - Is a standalone task in the plan, not embedded in the implementation task description
 - Uses `TEST_CMD` (resolved from `commands.test` in workflow-config) as the verify command
+- **Must be a behavioral test** — see Behavioral Test Requirement below
+
+#### Behavioral Test Requirement
+
+RED tests must verify **behavior** (what the code does), not **presence** (that specific code text exists in a source file). A test that greps a source file for a function name, string pattern, or implementation detail is a **change-detector test** — it passes when the code is written and fails when it's deleted, regardless of whether the code actually works.
+
+**A valid RED test must do at least one of:**
+- Execute the code under test and assert on its output, exit code, or side effects
+- Create test fixtures (files, repos, mock services) and verify the code handles them correctly
+- Import a module/function and call it with inputs, asserting the return value
+
+**Structural tests are acceptable ONLY for these categories:**
+- **Negative constraints** ("must NOT contain X") — e.g., no hardcoded paths after a migration, no relative paths in hook libs. These protect against regression to a known-bad state.
+- **Metadata/schema validation** — e.g., skill frontmatter has required fields, config file has required keys. These verify structure that has no executable behavior.
+- **Syntax checks** — `bash -n`, `python -m py_compile`, JSON schema validation. These verify the code is parseable.
+- **File existence/permissions** — `test -f`, `test -x`. These verify deployment prerequisites.
+
+**Structural tests are NOT acceptable for:**
+- Asserting that a function name appears in a source file (use: call the function)
+- Asserting that a string appears near another string via `sed -n` range extraction (use: create the scenario and verify the behavior)
+- Counting `grep -c` matches as a proxy for "feature is implemented" (use: exercise the feature)
+- Verifying a script handles edge cases by grepping for the edge case code (use: create the edge case input and verify the output)
+
+When the TDD task description specifies the RED test, it must include a **test approach** sentence explaining what the test executes and what output/behavior it asserts. If the test approach describes grepping a source file, the task must be revised to describe a behavioral assertion instead.
 
 #### Unit Test Exemption Criteria