[codex] Add team validation playbook

README.md

@@ -221,6 +221,9 @@ free Action is useful but your team needs shared policy packs, org-wide
 baselines, Slack or Jira routing, saved reports, or reviewer assignment, open a
 [team pilot request](https://github.com/Conalh/TaskBound/issues/new?template=team-pilot.yml).
 
+The outreach and evidence rules are documented in the
+[Team Validation Playbook](docs/TEAM_VALIDATION_PLAYBOOK.md).
+
 The current validation gate is tracked in
 [Validate paid team layer from OSS Action traction](https://github.com/Conalh/TaskBound/issues/8):
 external installs first, real feedback next, paid or pilot demand before hosted

docs/TEAM_VALIDATION_PLAYBOOK.md

@@ -0,0 +1,110 @@
+# Team Validation Playbook
+
+TaskBound should prove team demand from the free GitHub Action before any hosted
+SaaS work starts. This playbook defines the evidence to collect, how to ask for
+it, and what does not count.
+
+## Current Proof
+
+- Stable Action tag: `Conalh/TaskBound@v0.2.1`
+- Public demo PR: [Fix header CSS styling](https://github.com/Conalh/TaskBound/pull/1)
+- Paid-layer tracker: [Validate paid team layer from OSS Action traction](https://github.com/Conalh/TaskBound/issues/8)
+- Team intake: [team pilot request](https://github.com/Conalh/TaskBound/issues/new?template=team-pilot.yml)
+
+The demo shows a CSS-only stated task with out-of-scope workflow, MCP,
+dependency, lifecycle-script, package, and network-fetch changes. That is useful
+proof for the free Action. It is not proof that teams will pay.
+
+## Target Teams
+
+Prioritize teams that already use AI coding agents in pull requests and have
+felt review pain from broad, unrelated, or surprising agent edits. The best
+early teams have at least one real repository where TaskBound can run on live PRs
+in advisory mode.
+
+Do not pitch this as a hosted dashboard. Pitch it as a free Action that helps
+reviewers see whether an agent stayed inside the stated task.
+
+## Install Ask
+
+Ask teams to run TaskBound on one or two real pull requests with `fail-on: none`
+so it cannot block their workflow while the signal is being evaluated.
+
+```yaml
+name: TaskBound
+
+on:
+  pull_request:
+
+permissions:
+  contents: read
+
+jobs:
+  taskbound:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          fetch-depth: 0
+
+      - uses: Conalh/TaskBound@v0.2.1
+        with:
+          fail-on: none
+```
+
+If a team wants a narrower first run, ask them to add explicit pull request body
+scope such as "Only touch `src/auth/session.ts` and related tests." TaskBound
+uses the PR title plus body as scope context.
+
+## Feedback Ask
+
+For each team, collect feedback tied to a real PR or install attempt:
+
+- False positives: files TaskBound flagged that the team considers in scope.
+- Missing signals: risky scope creep that TaskBound did not flag.
+- Scope-source issues: places where the PR title or body did not express the
+  intended task clearly enough.
+- Policy tuning needs: severity overrides, repo-specific sensitive surfaces, or
+  different blocking thresholds.
+- Team workflow needs: shared policy packs, org-wide baselines, Slack or Jira
+  routing, saved reports, reviewer assignment, or report history.
+
+Open a public issue when the team can share details. Use a redacted note in
+issue #8 when the team cannot share repository details publicly.
+
+## Evidence Protocol
+
+Only count external evidence in issue #8.
+
+- Count an install when an external repository opens an install PR or runs the
+  Action on at least one real pull request.
+- Count feedback when it comes from a real team using or attempting to use
+  TaskBound, not from internal demos.
+- Count team-layer demand when the requested capability is unnecessary for the
+  free Action but useful for multiple people or repositories.
+- Count pilot or payment demand only when a team explicitly says it would pay,
+  budget for, or run a pilot around a team-layer capability.
+- Do not count TaskBound's demo PR, self-dogfood runs, README edits, or private
+  assumptions as market evidence.
+
+When evidence lands, update issue #8 with the repository or team name when
+public, a link to the PR or issue when available, and the counter it affects.
+
+## Outreach Loop
+
+1. Ask the team to install the free Action with `fail-on: none`.
+2. Let it run on one or two real PRs that include AI-agent edits.
+3. Review the TaskBound report with the team.
+4. Ask what was noisy, what was missing, and what would make the signal useful
+   across their team.
+5. Record concrete evidence in issue #8.
+6. Defer paid product work until the tracker has external signal.
+
+## Stop And Go Gates
+
+Do not build a SaaS dashboard while the issue #8 counters are at zero.
+
+Build only a thin team layer after external evidence appears. The first paid
+surface should match the demand teams actually report, not a guessed product
+shape. Likely candidates are shared policy configuration, org defaults, report
+history, notification routing, or reviewer assignment.