Add a dogfood workflow or clarify why the DeployBot repo does not run DeployBot

[coygeek]

Summary

The repository contains DeployBot registry labels/comments and extensive docs for installing examples/github-workflow.yml, but the default branch currently does not have an active DeployBot workflow. The only active workflow reported by GitHub is CI.

That makes the project harder to evaluate because users cannot tell whether DeployBot is intentionally not dogfooded, temporarily disabled, or only operated manually.

Evidence

gh workflow list --repo Forward-Future/DeployBot --all --json name,path,state,id reports:

[
  {
    "name": "CI",
    "path": ".github/workflows/ci.yml",
    "state": "active"
  }
]

Running deploybot doctor against the repository with the example policy reports:

{
  "check": "event-worker",
  "status": "warn",
  "detail": "No active DeployBot workflow was found",
  "hint": "Install examples/github-workflow.yml on the default branch."
}

At the same time, the repo has a DeployBot delivery registry issue and DeployBot metadata comments, so there is evidence of DeployBot-related operation.

Impact

For a project whose purpose is to coordinate merges, dogfooding is an important trust signal.

Without an active workflow or explicit explanation:

• users cannot see a canonical self-installation;
• agent onboarding has no live example to compare against;
• doctor appears to warn on DeployBot's own repository;
• the relationship between registry comments, manual operation, and the GitHub Action is unclear.

This does not mean the code is wrong, but it is a friction point for adoption.

Proposed fix

Choose one of these paths:

1. Add .github/workflows/deploybot.yml that uses the pinned DeployBot Action from examples/github-workflow.yml, adapted to this repo's actual checks and release policy.
2. Or document explicitly in the README why the DeployBot repository does not run the DeployBot workflow on itself.

If dogfooding is intentionally disabled, the docs could say:

This repository uses DeployBot metadata manually but does not install the DeployBot GitHub Action on main because ...

If dogfooding is enabled, deploybot doctor should be clean or should document any expected warnings.

Acceptance criteria

• A new evaluator can tell whether this repository is expected to run DeployBot on itself.
• If the repo dogfoods DeployBot, an active DeployBot workflow exists on the default branch.
• If the repo does not dogfood DeployBot, the README explains why and how its registry metadata is produced.
• The example policy or self-policy uses this repo's actual check display names, not just the workflow name.

Verification

• gh workflow list --repo Forward-Future/DeployBot --all --json name,path,state,id
• deploybot --repository Forward-Future/DeployBot --config <self-policy> doctor --json