chore: adopt override principles in CI, skills and docs

[KJonline]

What does this change?

Writes down why this repo exists, and makes CI, the release check and the Claude Code skills follow it.

Principles (new CLAUDE.md, summarised in MAINTAINING.md and the README)

1. Extend core and reuse it wherever possible. This component replaces core's hive integration to add capability, but re-exports core's platforms instead of copying them.
2. It's an opt-in fast channel. Installing this component opts in to changes before core ships them, and its HACS betas are the testing channel. It may pin a newer pyhive-integration than core, including pre-releases, but pre-release pyhive only ships in component betas.

Why master is red today
hassfest now checks a custom integration's requirements against every core integration's pins, including core hive's own pyhive-integration==1.0.9. Because this component replaces core hive, that check always reports an error:

• ==1.0.9 (master): "pins a package Home Assistant depends on"
• ==2.0.0b4 (release: 2026.10.1b2 (pyhive-integration 2.0.0b4) #214): "is incompatible with pyhive-integration==1.0.9, which Home Assistant depends on"

HA doesn't constrain pyhive-integration at install time; it isn't in package_constraints.txt. So this only affects hassfest, not users.

Changes

• .github/scripts/hassfest.py: runs the official ghcr.io/home-assistant/hassfest image, the same one home-assistant/actions/hassfest runs, and reports only pyhive-integration differences from core hive's pin as warnings. Every other error still fails, including conflicts with HA's own dependencies or package constraints. ci.yml and compat.yml use it, and the job names are unchanged, so the required checks still match.
• check_release.py: a stable release that pins a pre-release pyhive-integration fails the Release run.
• ci.yml: fixes "Re-enable scheduled workflows", which has failed on every push because gh workflow view doesn't accept --json on the runner. It now uses gh api.
• Skills:
  • /release checks PyPI for the newest pyhive, pre-releases included, before a beta, and blocks a stable release with a pre-release pin.
  • /bump-pyhive gets a working download step, plus the offline sample-data test and the exception-mapping checks.
  • /triage-compat and /repo-health treat the hassfest warning as expected.

Verification

• I ran the wrapper locally against the real hassfest image:

  Manifest pin	Result
  ==1.0.9	Warning, passes
  ==2.0.0b4	Warning, passes
  Beta pin plus a forbidden aiohttp==3.0.0 requirement	Fails on the aiohttp error

• check_release.py: a stable release with a stable pin passes, a beta with a beta pin passes, and a stable release with a beta pin fails.

• gh api repos/.../actions/workflows/compat.yml --jq .state returns active.

• script/test: 80 passed. script/lint --check: clean.

Worth raising upstream: hassfest could exempt a custom integration from conflicts with the pins of the core integration it replaces. Then this wrapper could go.

Related issues

Unblocks #214, whose Hassfest check fails on the same rule.

Checklist

• Tests added or updated, and script/test passes
• script/lint --check passes (after script/lint, which also regenerates translations)
• If this is going into a release: bumped version in manifest.json (not a release)

🤖 Generated with Claude Code