doctorlisted

# keel doctor ## 1. Gather the state git rev-parse --show-toplevel git symbolic-ref --short HEAD git remote -v gh repo view --json viewerPermission -q .viewerPermission cat .keel.json gh auth status ## 2. Report what keel sees - config: topology, protected branches (production/integration), review policy, merge strategies, whether a changelog is required - current branch, and which kind keel classifies it as (production, integration, feature, release, hotfix, or other) - your permission level, and whether `gh` is authenticated ## 3. Explain the block If keel denied something, the message carried a rule name in brackets. If more than one rule fired, the first bracketed name is the primary reason; anything after `Also: [rule] ...` fired too but wasn't the blocking cause - worth fixing, but not why the command stopped. What each name means: - **`protected-write`** - the commit or push targets a protected branch (matched by name - `production` or `integration` from `.keel.json`). For a push, keel reads the *destination* refspec, so `git push origin HEAD:main` counts as targeting `main` even from a feature branch. Use `keel:start-work` instead of committing or pushing directly. **Known limitation:** this check matches on branch *name*, not on which repo or remote owns it. keel cannot tell your fork's own `main` apart from the canonical repo's `main` - both are just a branch named `main`. So pushing to `main` on a fork you fully c